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Elasticsearch 权威 指南 


项 目 信息 


在 线 阅 读 


国外 自动 指向 GITBOOK 项 目 | 国内 用 户 自动 指向 阿里 云 


GITHUB 仓库 


译 者 前 言 


译 者 现在 的 工作 项 目 中 需要 用 到 Elasticsearch， 但 是 在 网 络 中 找 了 很 多 的 相关 的 内 容 都 很 不 
完善 ， 中 文 的 文档 更 是 察 察 无 几 ， 所 以 我 决定 边 研究 边 翻 译 一 下 官方 推出 的 权威 手册 。 在 这 
里 要 先 感谢 原作 者 们 ! 如 果 各 位 在 这 里 发 现 了 错误 之 处 ， 请 大 家 在 Issue 中 提出 或 者 PR 这 个 
项 目 o 


如 果 你 喜欢 这 个 翻译 项 目 可 以 点 击 Star 一 下 ， 您 的 支持 是 我 们 最 大 的 动力 。 


原作 名 字 : elasticsearch - the definitive guide 
原作 作者 : clinton gormley，zachary tong 


译 者 : Gavin Foo fuxiaopang@gmail.com 


这 本 书 还 在 不 断 地 添加 内 容 中 ， 我 们 会 陆 陆续 续 地 在 这 里 添加 新 的 章节 。 这 本 书 中 的 内 容 针 
对 的 是 Elasticsearch 的 最 新 版 本 。 


欢迎 反馈 一 如 果 这 里 出 现 了 错误 ， 或 者 你 有 什么 建议 可 以 到 我 们 GitHub 项 目 中 新 建 一 个 


issue ° 


这 个 世界 已 经 被 数据 淹没 。 我 们 创造 的 系统 所 产生 的 数据 可 以 瞬间 轻而易举 地 将 我 们 压 垮 ， 
现 有 的 科技 一 直 致 力 于 如 何 存储 数据 ， 并 能 将 拥有 大 量 信息 的 数据 仓库 结构 化 。 而 当 你 准备 
开始 从 大 量 的 数据 中 得 出 结论 做 决策 的 时 候 ， 美 好 的 一 天 就 要 被 级 灭 了 ..... 


Elasticsearch 是 一 个 分 布 式 可 扩展 的 实时 搜索 和 分 析 引 敬 。 它 能 帮助 你 搜索 、 分 析 和 浏览 数 
据 ， 而 往往 大 家 并 没有 在 某 个 项 目 一 开始 就 预料 到 需要 这 些 功 能 。Elasticsearch 之 所 以 出 现 
就 是 为 了 重新 赋予 硬盘 中 看 似 无 用 的 原始 数据 新 的 活力 。 


无 论 你 是 需要 全 文 搜 索 、 结 构 化 数据 的 实时 统计 ， 还 是 两 者 的 结合 ， 这 本 指南 都 会 帮助 你 了 
解 其 中 最 基本 的 概念 ， 从 最 基本 的 操作 开始 学 习 Elasticsearch。 之 后 ， 我 们 还 会 逐渐 开始 探 
索 更 加 复杂 的 搜索 技术 ， 你 可 以 根据 自身 的 学 习 的 步伐 。 

Elasticsearch 并 不 是 单纯 的 全 文 搜 索 这 么 简单 。 我 们 将 向 你 介绍 讲解 结构 化 搜索 、 统 计 、 查 
询 过 滤 、 地 理 定位 、 自 动 完 成 以 及 你 是 不 是 要 查找 的 提示 。 我 们 还 将 探讨 如 何 给 数据 建 模 能 
提升 Elasticsearch 的 性 能 ， 以 及 在 生产 环境 中 如 何 配置 、 监 视 你 的 集群 。 


AT] 

Elasticsearch 是 一 个 实时 的 分 布 式 搜 索 和 分 析 引 擎 。 它 可 以 帮助 你 用 前 所 未 有 的 速度 去 处 理 
大 规模 数据 。 

它 可 以 用 于 全 文 搜 索 ， 结 构 化 搜索 以 及 分 析 ， 当 然 你 也 可 以 将 这 三 者 进行 组 合 


。 维基 百科 使 用 Elasticsearch 来 进行 全 文 搜 索 并 高 亮 显示 关键 词 ， 以 及 提供 search-as- 
you-type、did-you-mean 等 搜索 建议 功能 。 

英国 卫 报 使 用 Elasticsearch 来 处 理 访客 日 志 ， 以 便 能 将 公众 对 不 同文 章 的 反应 实时 地 反 
馈 给 各 位 编辑 。 


StackOverflow 将 全 文 搜 索 与 地 理 位 置 和 相关 信息 进行 结合 ， 以 提供 more-like-this 相 关 问 
题 的 展现 。 


GitHub 使 用 Elasticsearch 来 检索 超过 1300 亿 行 代 码 。 


e 每 天 ，Goldman Sachs 使 用 它 来 处 理 5TB 数 据 的 索引 ， 还 有 很 多 投行 使 用 它 来 分 析 股 票 
市 场 的 变动 。 


但 是 Elasticsearch 并 不 只 是 面向 大 型 企业 的 ， 它 还 帮助 了 很 多 类 似 DataDog 以 及 Klout 的 创 
业 公 司 进行 了 功能 的 扩展 。Elasticsearch 可 以 运行 在 你 的 笔记 本 上 ， 也 可 以 部 署 到 成 千 上 万 
的 服务 器 上 ， 处 理 PB 级 别 的 数据 。 


Elasticsearch 每 一 个 独立 的 部 分 都 不 是 新 创 的 。 比 如 全 文 搜 索 早 就 已 经 被 实现 ， 统 计 系统 和 
分 布 式 数据 库 也 早已 存在 。 但 是 革命 之 处 在 于 能 将 这 些 独 立 的 功能 结合 成 一 个 连贯 、 实 时 处 
理 的 整体 。 对 于 新 用 户 ， 它 的 门槛 也 很 低 ， 当 然 他 也 会 因为 你 的 强大 而 变 得 更 强大 。 


你 之 所 以 拿 起 这 本 书 ， 就 是 因为 你 眼前 有 很 多 的 数据 ， 但 是 你 并 不 知道 如 何 使 用 他 们 ， 接 下 
来 我 们 将 开始 探讨 有 关 处 理 数据 的 事情 。 

很 不 幸 的 是 ， 目 前 的 大 部 分 数据 库 在 提取 数据 方面 都 是 非常 的 薄弱 的 。 虽 然 它 们 可 以 通过 精 
准 的 时 间 惟 或 者 确切 的 数值 来 进行 内 容 的 筛选 ， 但 是 它们 可 以 在 全 文 搜索 时 做 到 同义词 或 者 
相关 性 搜索 吗 ? 他 们 可 以 汇总 相同 内 容 数据 吗 ? 最 重要 的 是 ， 每 对 如 此 巨大 的 数据 量 ， 它 们 
能 做 到 实时 处 理 吗 ? 


这 便 是 Elasticsearch 如 此 突出 的 理由 : Elasticsearch 可 以 帮助 你 浏览 并 利用 已 经 快要 烂 在 数 
据 库 里 的 那些 极 难 查询 的 数据 。 


Elasticsearch 将 会 成 为 你 一 生 的 小 伙伴 。 


AT] 


You Know, for Search... 


Elasticsearch 是 一 个 建立 在 全 文 搜索 引擎 框架 Apache Lucene(TM) 基础 上 的 开源 搜索 引擎 ， 
无 论 是 开源 软件 还 是 私有 软件 ，Lucene 都 毫 无 疑问 是 当今 最 先进 、 性 能 最 高 和 功能 最 全 的 搜 
索引 擎 框架 。 


但 是 Lucene 只 是 一 个 框架 ， 要 充分 使 用 它 的 功能 ， 你 需要 使 用 JAVA 作为 开发 语言 ， 并 且 在 
你 的 程序 中 集成 Lucene。 更 糟 的 是 ， 你 需要 深入 了 解 相 关 知 识 才 能 明白 它 是 如 何 运 行 的 ， 
Lucene 确实 非常 复杂 。 


Elasticsearch 也 是 使 用 Java 编写 的 ， 并 且 采 用 了 Lucene 来 实现 索引 与 搜索 的 功能 。 而 且 ， 
aed 它 做 全 文 搜索 时 ， 只 需要 使 用 简单 流畅 的 RESTful API 即 可 ， 并 不 需要 了 解 Lucene 
后 复杂 的 的 运行 原理 。 


当然 Elasticsearch 还 有 很 多 地 方 超越 了 Lucene， 它 不 仅 可 以 实现 全 文 搜索 功能 ， 还 可 以 完 
成 以 下 工作 : 


。 分 布 式 实时 文档 存储 ， 并 将 每 一 个 字段 都 编 入 索引 ， 使 其 可 以 被 搜索 。 
。 分 布 式 实时 分 析 与 搜索 引擎 。 
e 可 以 扩展 到 上 百 台 服务 器 ， 处 理 PB 级 别 的 结构 化 或 非 结构 化 数据 。 


么 多 的 功能 被 集成 到 一 台 服 务 器 上 ， 你 可 以 轻松 地 通过 客户 端 或 者 任何 你 喜欢 的 程序 语言 
与 Elasticsearch 的 RESTful API 进行 通信 。 


Elasticsearch etka aia 。 它 附带 了 很 多 非常 合理 的 默认 值 ， 这 让 初 — 
免 一 上 手 就 要 面 对 复 杂 的 理论 。 安 装 完 成 就 可 以 马上 投入 使 用 了 。 不 需要 了 解 很 多 ， 你 就 能 
变 得 非常 有 生产 力 。 


随 着 学 习 的 深入 ， 你 还 可 以 使 用 Elasticsearch 更 多 高 级 的 功能 。 整 个 引擎 可 以 很 灵活 地 进行 
配置 。 你 可 以 根据 自身 需求 来 定制 属于 你 自己 的 Elasticsearch 。 


你 可 以 随意 下 载 、 使 用 、 修 改 Elasticsearch。 它 采用 Apache 2 license 进行 授权 ， 这 是 当前 
最 灵活 的 开源 授权 方式 。 源 代码 托管 在 Github 之 上 : github.com/elastic/elasticsearch 
Elasticsearch 在 Apache 2 license 下 许可 使 用 ， 可 以 免费 下 载 、 使 用 和 修改 。 如 果 你 愿意 加 
入 我 们 非常 优秀 的 贡献 者 社区 ， 请 参考 : Elasticsearch 贡献 。 


如 果 你 对 Elasticsearch 的 功能 、 插 件 、SDK 等 任何 方面 有 疑问 ， 都 可 以 在 这 里 提出 
discuss.elastic.co °> elastic 中 文 社区 。 


回忆 时 光 


多 年 以 前 ， 有 个 叫 Shay Banon 的 失业 开发 者 跟随 他 的 新 婚 妻 子 来 到 了 伦敦 ， 因 为 他 妻子 将 
在 那里 学 习性 艺 。Shay 在 寻找 工作 的 同时 ， 开 始 研究 还 是 早期 版 本 的 Lucene， 并 打算 为 她 
妻子 制作 一 个 京 饪 菜谱 搜索 引擎 。 


直接 基于 Lucene 工作 会 比较 困难 ， 所 以 Shay 开始 实现 一 个 Lucene 之 上 的 抽象 层 ， 这 样 
Java 程序 员 可 以 很 方便 的 为 他 们 的 应 用 程序 添加 搜索 功能 。 于 是 他 发 布 了 自己 的 第 一 个 开源 
项 目 “Compass”。 


后 来 Shay 找到 了 一 份 工 作 ， 这 份 工 作 主 要 围绕 在 高 性 能 与 分 布 式 内 存 数 据 存 储 的 环境 中 。 高 
性 能 、 实 时 、 分 布 式 搜索 引擎 是 必 不 可 少 的 需求 。 因 此 他 决定 重 写 Compass 库 ， 使 其 成 为 一 
个 独立 的 服务 器 ， 这 便 是 Elasticsearch 。 

2010 年 的 2 月 份 ， 第 一 个 公开 版 本 发 布 了 。 从 此 之 后 ，Elasticsearch 成 为 Github 上 最 受 欢迎 
的 项 目 之 一 ， 超 过 300 个 代码 贡献 者 。 一 家 关于 Elasticsearch 的 公司 就 此 成 立 ， 它 们 不 仅 提 

供 商 业 支 持 还 在 进行 新 功能 的 开发 ， 但 是 Elasticsearch 一 定 会 永远 向 大 众 开 放 ， 永 远 开源 给 
所 有 需要 的 人 们 。 


噢 ， 对 了 ，Shay 的 妻子 还 在 等 待 着 她 的 菜谱 搜索 引擎 。 


RR JAVA 


yum install java-1.7.0-openjdk -y 


装 并 运行 Elasticsearch 


了 解 Elasticsearch 最 简单 的 方法 就 是 去 使 用 它 ， 让 我 们 一 起 开始 探索 之 旅 吧 | 
装 Elasticsearch 只 有 一 个 要 求 ， 那 就 是 需要 安装 最 新 版 本 的 Java。 而且 最 好 从 Java 官网 
www.java.com 下 载 最 新 版 本 的 Java 来 安装 。 


你 可 以 从 这 里 获取 到 最 新 版 本 的 Elasticsearch : elastic.co/downloads/elasticsearch ° 


要 安装 Elasticsearch， 你 需要 下 载 并 解压 对 应 运行 平台 的 压缩 文件 。 更 多 相关 信息 请 参考 
Elasticsearch Reference ° 


TIP 


当 你 在 生产 环境 中 安装 Elasticsearch 时 ， 你 可 以 选择 使 用 Debian XA RPM 的 安装 包 ， 地 址 如 下 : [downl 
oads page](http://www.elastic.co/downloads/elasticsearch)。 你 也 可 以 使 用 官方 提供 的 [Puppet 

module](https://github.com/elasticsearch/puppet-elasticsearch) 或 者 [Chef cookbook] (htt 
ps://github.com/elasticsearch/cookbook-elasticsearch) ° 


解压 完成 后 ，Elasticsearch 就 已 经 准备 就 绪 ， 等 待 运行 了 。 执 行 以 下 命令 便 可 在 前 台 局 动 


€: 


cd elasticsearch-<version> 
./bin/elasticsearch <1> <2> 


1. 如 果 你 想 在 后 台 以 守护 进程 模式 运行 它 ， 请 添加 -d 参数 。 


2. toe Windows 中 运行 Elasticsearch， 只 需要 运行 bin\elasticsearch.bat PPT ° 


你 可 以 在 另 一 个 终端 窗口 中 运行 以 下 命令 来 验证 它 是 否 成 功 运行 : 


curl 'http://localhost:9200/?pretty' 


TIP: 如 果 是 在 Windows 中 运行 Elasticsearch， 你 可 以 从 http:Wcurl.haxx.se/download.html 
下 载 CURL。 安 装 后 ， 遍 可 以 通过 简单 地 向 Elasticsearch 提交 请 求 。 并 且 你 也 可 以 直 
接 复 制 粘贴 本 书 中 众多 的 例子 ， 通 过 CURL 来 运行 与 试验 。 


你 会 看 到 如 下 的 返回 信息 : 


{ 
"name" : "Tom Foster", 
"cluster_name" : "elasticsearch", 
"version" : { 
"number" » "2.1.0", 
"build_hash" : "72cdifla3eee09505e036106146dc1949dc5dc87", 
"build timestamp" : "2015-11-18T22:40:03Z", 
"build_snapshot" : false, 
"Jucene_version" : "5.3.1" 
}, 
"tagline" : "You Know, for Search" 
} 


SENSE: 010_Intro/10_Info.json 


这 说 明 你 已 经 开启 并 运行 了 一 个 ELasticsearch 节点 ， 接 下 来 就 可 以 开始 各 种 实验 了 。 节 点 
(node) 是 Elasticsearch 中 的 一 个 运行 实例 。 集 群 (Cluster) 是 一 个 包含 了 多 个 拥有 相同 
cluster ,name 节点 的 分 组 ， 这 些 节点 协同 工作 以 共享 数据 ， a 

可 能 性 。 (一 个 节 WA ) 你 可 以 在 配置 文件 elasticsearch.yml 中 修改 
cluster.name ， 每 当 节 点 启动 时 ， 这 些 配 置 文件 就 会 被 加 载 。 更 多 相关 信 ， n 

后 关于 生产 部 署 部 分 的 《important-configuration-changes, 重要 的 配置 修改 》 章 


TIP: 看 到 例子 下 方 的 View in Sense 链接 了 吗 ? sense, 安装 Sense 控制 台 》 便 可 以 在 自 
己 的 Elasticsearch 集群 中 运行 本 书 中 的 例子 ， 并 直接 查看 结果 了 。 


当 Elasticsearch 已 经 在 前 台 运 行 时 ， 你 可 以 按 下 Ctrl-C 来 终止 这 个 进程 。 


z% Sense 


Sense 是 一 个 Kibana 程序 ， 它 的 交互 式 控制 台 可 以 帮助 你 直接 通过 浏览 器 向 Elasticsearch 

提交 请 求 。 在 本 书 的 在 线 版 中 ， 众 多 的 代码 示例 都 包含 了 View in Sense 链接 。 当 你 点 击 之 

后 ， 它 将 自动 在 Sense 控制 台中 运行 这 段 代码 。 你 并 不 是 一 定 要 安装 Sense， 但 那 将 失去 很 
多 与 本 书 的 互动 以 及 直接 在 你 本 地 的 集群 中 的 实验 代码 的 乐趣 。 


装 并 运行 Sense: 


在 Kibana 的 目录 中 运行 以 下 命令 以 下 载 并 安装 Sense 程序 : 


./bin/kibana plugin --install elastic/sense <1> 


1. Windows: bin\kibana. bat plugin --install elastic/sense . 


NOTE: 如 果 需 要 离线 安装 Sense， 你 可 以 从 这 里 直接 下 载 : 
https://download.elastic.co/elastic/sense/sense-latest.tar.gz ° 


运行 Kibana. 
./bin/kibana <1> 


1. Windows: bin\kibana.bat . 


2 


在 浏览 器 中 访问 http://localhost :5601/app/sense 就 可 以 使 用 Sense 了 。 


x 
— 


与 Elasticsearch 通信 


如 何 与 Elasticsearch 通信 要 取决 于 你 是 否 使 用 JAVA ° 


Java API 


如 果 你 使 用 的 是 JAVA? Elasticsearch 内 置 了 两 个 客户 端 ， 你 可 以 在 你 的 代码 中 使 用 : 


节点 客户 端 : 节点 客户 端 以 一 个 无 数据 节点 的 身份 加 入 了 一 个 集群 。 换 名 话说 ， 它 自身 是 没 
— 的 ， 但 是 他 知道 什么 数据 在 集群 中 的 哪 一 个 节点 上 ， 然 后 就 可 以 请 求 转发 到 正确 
的 节点 上 并 进行 连接 。 


传输 客户 端 更 加 轻 量 的 传输 客户 端 可 以 被 用 来 向 远程 集群 发 送 请 求 。 他 并 不 加 入 集群 本 身 ， 
而 是 把 请 求 转 发 到 集群 中 的 节点 


这 两 个 客户 端 都 使 用 Elasticsearch a leg 协议 ， 通 过 9300 端 口 与 java 客户 端 进 行 通信 。 集 


群 中 的 各 个 节点 也 是 通过 9300 端 口 进 言 。 如 果 这 个 端口 被 禁止 了 ， 那 么 你 的 节点 们 将 不 
能 组 成 一 个 集群 。 


TIP 


Java 的 客户 端的 版 本 号 必须 要 与 Elasticsearch 节点 所 用 的 版 本 号 一 样 ， 不 然 他 们 之 间 可 能 
法 识别 。 


更 多 关于 Java API 的 说 明 可 以 在 这 里 找到 Guide. 


通过 HTTP 向 RESTful API 传送 json 


其 他 的 语言 可 以 通过 9200 端 口 与 Elasticsearch 的 RESTful API 进行 通信 。 事 实 上 ， 如 你 所 
见 ， 你 其 至 可 以 使 用 行 命令 curl 来 与 Elasticsearch 通信 。 


Elasticsearch 官方 提供 了 很 多 种 编程 语言 的 客户 端 ， 也 有 和 许多 社区 化 软件 的 集成 插件 ， 这 
些 都 可 以 在 Guide 里 面 找 到 。 


向 Elasticsearch 发 出 的 请 求 和 其 他 所 有 的 HTTP 请 求 的 组 成 部 分 是 一 致 的 。 人 例如， 计算 集 群 
中 文件 的 数量 ， 我 们 就 可 以 使 用 : 


<i> <2> <3> <4> 

curl -XGET 'http://localhost:9200/_count?pretty' -d ' 
{ <5> 

"query": { 

"match_all": {} 

} 
} 
1. 相应 的 HTTP 请 求 方法 或 者 变量 : GET, POST, PUT, HEAD 或 者 DELETE ° 
2， 集 群 中 任意 一 个 节点 的 访问 协议 、 主 机 名 以 及 端口 。 
3. 请 求 的 路 径 。 
4. 任意 一 个 查询 后 再 加 上 pretty 就 可 以 生成 更 加 美观 的 JSON 反 馈 ， 以 增强 可 读 性 
5. 一 个 JSON 编码 的 请 求 主体 (如果 需要 的 话 ) o 


Elasticsearch 将 会 返回 一 个 HTTP 状态 码 类 似 于 '200 OK'， 以 及 一 个 JSON 格式 的 主体 (R 
了 单纯 的 'HEAD' 请 求 ) ， 上 面 的 请 求 会 得 到 下 方 的 JSON EK: 


{ 
lero Tn eu : 0; 
es iancs ee 
Ola aS), 
"suceessful = 5, 
"failed" : 0 
} 
} 
在 反馈 中 ， 我 们 并 没有 看 见 HTTP 的 头 部 信息 ， 因 为 我 们 没有 告知 curl 显示 这 些 内 容 。 如 
果 你 想 看 到 头 部 信息 ， 可 以 在 使 用 curl 命令 的 时 候 再 加 上 -i ver : 
curl -i -XGET 'localhost:9200/' 
从 现在 开始 ， 本 书 里 所 有 涉及 curl 命令 的 部 分 我 们 都 会 进 因为 主机 、 端 口 等 信息 


都 是 相同 的 ， 缩 减 前 的 样子 : 


curl -XGET 'localhost:9200/_count?pretty' -d ' 
{ 
"query": { 
"match_all": {} 
} 
y 


我 们 将 会 简写 成 这 样 : 


GET /_count 
{ 
"query": { 
"match_all": {} 
} 


面向 文档 


程序 中 的 对 象 很 少 是 单纯 的 键 值 与 数值 的 列表 。 更 多 的 时 候 它 拥有 一 个 复杂 的 结构 ， 比 如 包 
AT AW. ARAE HH. MAF o 

迟早 你 会 把 这 些 对 象 存储 在 数据 库 中 。 你 会 试图 将 这 些 丰 富 而 又 庞大 的 数据 都 放 到 一 个 由 行 
与 列 组 成 的 关系 数据 库 中 ， 然 后 你 不 得 不 根据 每 个 字段 的 格式 来 调整 数据 ， 然 后 每 次 重建 它 
你 都 要 检索 一 遍 数 据 。 

Elasticsearch 是 面向 文档 型 数据 库 ， 这 意味 着 它 存储 的 是 整个 对 象 或 者 文档 ， 它 不 但 会 存储 
它们 ， 还 会 为 他 们 建立 索引 ， 这 样 你 就 可 以 搜索 他 们 了 。 你 可 以 在 Elasticsearch 中 索引 、 搜 
索 、 排 序 和 过 滤 这 些 文档 。 不 需要 成 行 成 列 的 数据 。 这 将 会 是 完全 不 同 的 一 种 面 对 数 据 的 思 
考 方式 ， 这 也 是 为 什么 Elasticsearch 可 以 执行 复杂 的 全 文 搜索 的 原因 。 


JSON 


Elasticsearch 使 用 JSON (或 称 作 JavaScript Object Notation ) 作为 文档 序列 化 的 格式 。 JSON 
已 经 被 大 多 数 语言 支持 ， 也 成 为 NOSQL 领域 的 一 个 标准 格式 。 它 简单 、 简 洁 、 多 于 阅读 。 


把 这 个 JSON 想象 成 一 个 用 户 对 象 : 


{ 
"email": "jJohn@smith.com", 
"first_name": "John", 
"last_name": "Smith", 
"about": { 
AHTO: "Eco-warrior and defender of the weak", 
Hagel: 257, 
interests: I dolphins, whales 
}, 
“join date“: "2014/05/01", 
} 


虽然 user 这 个 对 象 非常 复杂 ， 但 是 它 的 结构 和 含义 都 被 保留 到 JSON 中 了 。 在 
Elasticsearch 中 ， 将 对 象 转换 为 JSON 并 作为 索引 要 比 在 表 结 构 中 做 相同 的 事情 简单 多 了 。 


将 你 的 数据 转换 为 JSON 


几乎 所 有 的 语言 都 有 将 任意 数据 转换 、 机 构 化 成 JSON， 或 者 将 对 象 转换 为 JSON 的 模块 。 查 
看 serialization 以 及 marshalling 两 个 JSON 模块 。The official Elasticsearch clients 也 
可 以 帮 你 自动 结构 化 JSON © 


启程 


为 了 能 让 你 感受 一 下 Elasticsearch 能 做 什么 以 及 它 是 有 多 么 的 易 用 ， 我 们 会 先 为 你 简单 展示 
一 下 ， 其 中 包括 了 基本 的 创建 索引 ， 搜 索 以 及 聚合 。 


我 们 会 在 这 里 向 你 介绍 一 些 新 的 术语 以 及 简单 的 概念 ， 即 使 你 没有 马上 接受 这 些 概念 也 没有 
关系 。 我 们 会 在 之 后 的 章节 中 逐渐 帮 你 理解 它们 。 


所 以 ， 准 备 开 始 享受 Elasticsearch 的 学 习 之 旅 把 ! 


建立 一 个 员工 名 单 


想象 我 们 正在 为 一 个 名 叫 megacorp 的 公司 的 HR 部 门 制作 一 个 新 的 员工 名 单 系统 ， 这 些 名 
单 应 该 可 以 满足 实时 协同 工作 ， 所 以 它 应 该 可 以 满足 以 下 要 求 : 


© 数据 可 以 包含 多 个 值 的 标签 、 数 字 以 及 纯 文本 内 容 ， 
© 可 以 检索 任何 职员 的 所 有 数据 。 

© 允许 结构 化 搜索 。 例 如 ， 查 找 30 岁 以 上 的 员工 。 

o 允许 简单 的 全 文 搜索 以 及 相对 复杂 的 短语 搜索 。 

© 在 返回 的 匹配 文档 中 高 亮 关 键 字 。 

e 拥有 数据 统计 与 管理 的 后 台 。 


s 
s 


为 员工 档案 创建 索引 


这 个 项 目的 第 一 步 就 是 存储 员工 的 数据 。 这 样 你 就 需要 一 个 “员工 档案 "的 表单 ， 这 样 每 个 文档 
都 代表 着 一 个 员工 。 在 Elasticsearch 中 ， 存 储 数 据 的 行为 就 叫做 索引 (indexing) ， 但 是 在 我 
们 索引 数据 前 ， 我 们 需要 决定 将 数据 存储 在 哪里 。 


在 Elasticsearch 中 ， 文 档 属 于 一 种 类 型 ftype)， 各 种 各 样 的 类 型 存在 于 一 个 索引 中 。 你 也 可 
以 通过 类 比 传统 的 关系 数据 库 得 到 一 些 大 致 的 相似 之 处 : 


关系 数据 库 = 数据 库 = Š = 47 = (Columns) 
Elasticsearch -= 索引 = 类 型 > 文档 =” 字段 (Fields) 


一 个 Elasticsearch 集群 可 以 包含 多 个 索引 (数据库) ， 也 就 是 说 其 中 包含 了 很 多 类 型 
(R) 。 这 些 类 型 中 包含 了 很 多 的 文档 ( 行 ) ， 然 后 每 个 文档 中 又 包含 了 很 多 的 字段 
( 列 ) 。 


索引 索引 索引 


你 可 能 发 现在 Elasticsearch 中 ， 索 引 这 个 词汇 已 经 被 赋予 了 太 多 意义 ， 所 以 在 这 里 我 们 有 必 


索引 (名词 ) 


如 上 文 所 说 ， 一 个 索引 就 类 似 于 传统 关系 型 数据 库 中 的 数据 库 。 这 里 就 是 存储 相关 文档 的 的 
地 方 。 


索引 (动词 ) 


为 一 个 文档 创建 索引 是 把 一 个 文档 存储 到 一 个 索引 人 (名词 ) 中 的 过 程 ， 这 样 它 才能 被 检索 。 这 
个 过 程 非 常 类 似 于 SQL 中 的 INSERT 命令 ， 如 果 已 经 存在 文档 ， 新 的 文档 将 会 徐 盖 昌 的 文 
档 。 


在 关系 数据 库 中 的 某 列 添加 一 个 索引 ， 比 如 多 路 搜索 树 (B-Tree) 索 引 ， 就 可 以 加 速 数据 的 取 
回 速 度 Elasticsearch 以 及 Lucene 使 用 的 是 一 个 叫做 反 向 索引 (inverted index) 的 结构 来 实 
现 相同 的 功能 。 


通常 ， 每 个 文档 中 的 字段 都 被 创建 了 索引 (拥有 一 个 反 向 索引 ) ， 因 此 他 们 可 以 被 搜 
索 。 如 果 一 个 字段 缺失 了 反 向 索引 的 话 ， 它 将 不 能 被 搜索 。 我 们 将 会 在 之 后 的 《 反 向 索 


引 》 章 节 中 详细 介绍 它 。 


所 以 为 了 创建 员工 名 单 ， 我 们 需要 进行 如 下 操作 : 


© 为 每 一 个 员工 的 文档 创建 索引 ， 每 个 文档 都 包含 了 一 个 员工 的 所 有 信息 。 
© 每 个 文档 都 会 被 标记 为 employee 类 型 。 

这 种 类 型 将 存活 在 megacorp 这 个 索引 中 。 

这 个 索引 将 会 存储 在 Elasticsearch 的 集群 中 


在 实际 的 操作 中 ， 这 些 操作 是 非常 简单 的 (即使 看 起 来 有 这 么 多 步骤 ) 。 我 们 可 以 把 如 此 之 
多 的 操作 通过 一 个 命令 来 完成 : 


PUT /megacorp/employee/1 


{ 
-hustamame ss Johnie, 
"last_name" : "Smith", 
wage’ : 257 
"about" : "I love to go rock climbing", 


“interests": [ “sports”, "music" ] 


注意 在 /megacorp/employee/1 路 径 下 ， 包 含 了 三 个 部 分 : 


名 字 内 容 
megacorp 索引 的 名 字 

employee 类 型 的 名 字 

1 当前 员工 的 ID 


请 求 部 分 ， 也 就 是 JSON 文档 ， 在 这 里 包含 了 关于 这 名 员工 的 所 有 信息 。 他 的 名 字 是 “John 
Smith”， 他 已 经 25 岁 了 ， 他 很 喜欢 攀岩 。 


怎么 样 ?很 简单 吧 ! 我 们 在 操作 前 不 需要 进行 任何 管理 操作 ， 比 如 创建 索引 ， 或 者 为 字段 指 
定数 据 的 类 型 。 我 们 就 这 么 直接 地 为 一 个 文档 创建 了 索引 。Elasticsearch 会 在 创建 的 时 候 为 


它们 设 定 默 认 值 ， 所 以 所 有 管理 操作 已 经 在 后 台 被 默默 地 完成 了 。 


在 进行 下 一 步 之 前 ， 我 们 再 为 这 个 目录 添加 更 多 的 员工 信息 吧 : 


PUT /megacorp/employee/2 


{ 
"fFirst_name" : "Jane", 
"last_name" : Sn 
"age" : s27 
OU aik "T like to collect rock albums", 
"interests": [ "music" ] 
} 
PUT /megacorp/employee/3 
{ 
"first_name" : “Douglas", 
"last_name" : Eafe. 
de Sor 
Vabouits't: "I like to build cabinets", 
-ntenestse sss TOnESiEIsy. am 


检索 文档 
现在 ， 我 们 已 经 在 Elasticsearch 中 存储 了 一 些 数据 ， 我 们 可 以 开始 根据 这 个 项 目的 需求 进 
工作 了 。 第 一 个 需求 就 是 要 能 搜索 每 一 个 员工 的 数据 。 


对 于 Elasticsearch 来 说 ， 这 是 非常 简单 的 。 我 们 只 需要 执行 一 次 HTTP GET HR? AG 
出 文档 的 地 址 ， 也 就 是 索引 、 类 型 以 及 ID 即 可 。 通 过 这 三 个 部 分 ， 我 们 就 可 以 得 到 ae 
JSON 文档 : 


GET /megacorp/employee/i 


返回 的 内 容 包 含 了 这 个 文档 的 元 数据 信息 ， 而 John Smith 的 原始 ISON 文档 也 在 _source 
字段 中 出 现 了 : 


{ 
elie Xie: "megacorp", 
“typet : "employee", 
Malet" olka, 
PEVieieSdOn ime: i1, 
“roundi: true, 
“Sonce 人 
“first name One 
"last_name" : Smale 
"age" : 25, 
“aboutt: "I love to go rock climbing", 
"interests": [ "sports", "music" ] 
} 
} 


我 们 通过 将 HTTP 后 的 请 求 方式 由 PUT 改变 为 cet 来 获取 文档 ， 同 理 ， 我 们 也 可 以 将 其 更 
换 为 DELETE 来 删除 这 个 文档 ，HEAD 是 用 来 查询 这 个 文档 是 否 存 在 的 。 如 果 你 想 替 换 一 个 
已 经 存在 的 文档 ， 你 只 需要 使 用 PUT 再 次 发 出 请 求 即 可 。 


at 


简易 搜索 


GET 命令 真 的 相当 简单 ， 你 只 需要 告诉 它 你 要 什么 即 可 。 接 下 来 ， 我 们 来 试 一 下 稍微 复杂 一 
点 的 搜索 。 


我 们 首先 要 完成 一 个 最 简单 的 搜索 命令 来 搜索 全 部 员工 : 


GET /megacorp/employee/_search 


你 可 以 发 现 我 们 正在 使 用 megacorp 索引 ， employee 类 型 ， 但 是 我 们 我 们 并 没有 指定 文档 的 
ID， 我 们 现在 使 用 的 是 _search 端口 。 你 可 以 再 返回 的 hits 中 发 现 我 们 录入 的 三 个 文档 。 
搜索 会 默认 返回 最 前 的 10 个 数值 。 


EOOK 6, 
"timed_out": false, 


Sal dS af ane Sy 
Winkie af 
“totali: sh 
“max scoret: 1, 
ANIES] 
{ 
4 Ano eX "megacorp", 
Paty pew: "employee", 
Veal ugu 
SCO: aly, 


source. : i 


"first_name": "Douglas", 
lastaname | ll 
"age": Spr 
"about": Lh lake tombusldnicabinetsi:, 
"interests": [ "forestry" ] 
} 
}, 
{ 
“JnNndexX "megacorp", 
Stype "employee", 
Hite Ne Malas 
"n scoret: a 
PESOUNCE 人 
-hurst namek- m Jonni 
"last_name": "Smith", 
Wage": 257 
"about": "I love to go rock climbing", 
ntenests ale SPOKES. ma musac a 
} 
} 
{ 
“index: "megacorp", 
"_type”: "employee", 
wllo ie WN 
"_score": aly, 
SOUNCe WEE 
"first_name": "Jane", 
"last_name": SME 
"age": 32 
"about": Tke torcollect rock albums:s, 
"interests": [ "music" | 
} 
J 


注意 : 反馈 值 中 不 仅 会 告诉 你 匹配 到 哪些 文档 ， 同 时 也 会 把 这 个 文档 都 会 包含 到 其 中 : 我 们 
需要 搜索 的 用 户 的 所 有 信息 。 

接 下 来 ， 我 们 将 要 尝试 着 实现 搜索 一 下 哪些 员工 的 姓 反 中 包含 smith 。 为 了 实现 这 个 ， 我 们 
需要 使 用 一 种 轻 量 的 搜索 方法 。 这 种 方法 经 常 被 称 做 查询 字符 串 (query string) 搜索 ， 因 为 我 
们 通过 URL 来 传递 查询 的 关键 字 : 


GET /megacorp/employee/_search?q=last_name: Smith 


我 们 依旧 使 用 _search 端口 ， 然 后 可 以 将 参数 传 入 给 ge 。 这 样 我 们 就 可 以 得 到 姓 Smith 的 
结果 : 


{ 
MNase af 
"total": 2; 
"max_score": 0.30685282, 
Hehea | 
{ 
P=sounce sf 
"First_name": "John", 
"last_name": "Smith", 
"age": 297 
"about": "I love to go rock climbing", 
“interests: lsports “music™ | 
} 
} 
{ 
SOUrce mf 
"first_name": "Jane", 
"last_name": "Smith", 
"age": 327 
"about": "I like to collect rock albums", 
"interests": [ “music” ] 
} 
} 
] 
} 
} 


使 用 Query DSL 搜 索 


查询 字符 串 是 通过 命令 语句 完成 点 对 点 (ad hoc) 的 搜索 ， 但 是 这 也 有 它 的 局 限 性 (可 参阅 
章节 ) 。Elasticsearch 提供 了 更 加 丰富 灵活 的 查询 语言 ， 它 被 称 作 Query 
AK, 


成 更 加 复杂 、 强 大 的 搜索 任务 。 


《搜索 局 限 性 》 章 节 
DSL， 通 过 它 你 可 以 


DSL (Domain Specific Language 领域 特定 语言 ) 需要 使 用 JSON 作为 主体 ， 我 们 还 可 以 这 样 
查询 姓 Smith 的 员工 : 


GET /megacorp/employee/_search 


{ 
"query" : { 
smatch 
"last_name" : "Smith" 


} 


这 个 请 求 会 返回 同样 的 结果 。 你 会 发 现 我 们 在 这 里 没有 使 用 查询 字符 串 ， 而 是 使 用 了 一 个 由 
JSON 构成 的 请 求 体 ， 其 中 使 用 了 match 查询 法 ， 随 后 我 们 还 将 会 学 习 到 其 他 的 查询 类 型 。 


更 加 复杂 的 搜索 


接 下 来 ， 我 们 再 提高 一 点 儿 搜 索 的 难度 。 我 们 依 昌 要 了 寻找 出 姓 Smith 的 员工 ， 但 是 我 们 还 将 
添加 一 个 年 龄 大 于 30 岁 的 限定 条 件 。 我 们 的 查询 语句 将 会 有 一 些 细微 的 调整 来 以 识别 结构 化 
RR AH filter (过 滤器 ) : 


GET /megacorp/employee/_search 


{ 
OTSA Bat 
“filtered: af 
emiter BAe 
"range" : { 
fage ees Gite 330 1> 
} 
}, 
"query" : { 
maten {i 
"last_name" : "Smith" <2> 
} 
} 
} 
} 
} 


1， 这 一 部 分 的 语句 是 range filter， 它 可 以 查询 所 有 超过 30 岁 的 数据 -- gt 代表 greater 
than (大 于 ) 。 


2. 这 一 部 分 我 们 前 一 个 操作 的 match query 是 一 样 的 


先 不 要 被 这 么 多 的 语句 吓 到 ， 我 们 将 会 在 之 后 带 你 逐渐 了 解 他 们 的 用 法 。 你 现在 只 需要 知道 
我 们 添加 了 一 个 filter， 可 以 在 _ match 的 搜索 基础 上 再 来 实现 区 间 搜 索 。 现 在 ， 我 们 的 只 会 显 
示 32 几 的 名 为 Jane Smith 的 员工 了 : 


{ 
IES ef 
ota aly 
"max_score": 0.30685282, 
aes 
{ 
"source": { 
"first_name": "Jane", 
"last_name": ESMASE Ni 
Wage": 32, 
"about": "I like to collect rock albums", 
Vunternests ai Emus Ica] 
} 
} 
] 
} 
} 


DIRK 


上 面 的 搜索 都 很 简单 : 名 字 搜 索 、 通 过 年 龄 过 滤 。 接 下 来 我 们 来 学 习 一 下 更 加 复杂 的 搜索 ， 
全 文 搜索 一 一 一 项 在 传统 数据 库 很 难 实现 的 功能 。 我 们 将 会 搜索 所 有 喜欢 rock climbing 的 
员工 : 


GET /megacorp/employee/_search 
{ 
eu 人 
maECn ne 
"about" : "rock climbing" 


你 会 发 现 我 们 同样 使 用 了 match 查询 来 搜索 about 字段 中 的 rock climbing。 我 们 会 得 到 
两 个 匹配 的 文档 : 


SINS gs af 


“rotaliik 2; 
"max_score": 0.16273327, 
Aiesta Ii 
{ 
SCOWMe QO L6278327 <1> 
SOUrce { 
"first name": "John", 
"last_name": "Smith", 
"age": 25, 
"about": "I love to go rock climbing", 
"interests": [ "sports", "music" ] 
} 
} 
{ 
"score": ©.016878016, <1> 
"source": { 
"first_ name": "Jane", 
"last_name": "Smith", 
"age": 32, 
"about": "I like to collect rock albums", 
"interests": [ "music" ] 
} 
} 
] 
} 


1. 相关 评分 


通常 情况 下 ，Elasticsearch 会 通过 相关 性 来 排列 顺序 ， 第 一 个 结果 中 ，John Smith 的 about 
字段 中 明确 地 写 到 rock WE 。 而 在 Jane Smith 的 about 字段 中 ， 提 及 到 了 rock， 但 
是 并 没有 提 及 到 climbing ， 所 以 后 者 的 _score 就 要 比 前 者 的 低 。 


这 ATE T Elasticsearch 是 如 何 执行 全 文 搜索 的 。 对 于 Elasticsearch 来 说 ， 相 
关 性 的 概念 是 很 重要 的 ， 而 这 也 是 它 与 传统 数据 库 在 返回 匹配 数据 时 最 大 的 不 同 之 处 。 


LKK 


能 够 找 出 每 个 字段 中 的 独立 单词 固然 很 好 ， 但 ail! 时 候 你 可 能 还 需要 去 匹配 精确 的 短语 或 
者 段落 。 例 如， 我 们 只 需要 查询 到 about 字段 只 包含 rock climbing 的 短语 的 员工 。 


为 了 实现 这 个 效果 ， 我 们 将 对 match 查询 变 为 match_phrase 查询 : 


GET /megacorp/employee/_search 
{ 
KENNA 人 
"match_phrase" : { 
"about" : "rock climbing" 


这 样 ， 系 统 会 没有 异议 地 返回 John Smith 的 文档 : 


{ 
SMES af 
"totalit ily 
"max_score": 0.23013961, 
nants 
{ 
SCO 0.23013961, 
SOUrce i 
finst names: “Johnie, 
"last_name": "Smith", 
"age": 257 
"about": Pr loves tol go) voor ‘clambing =, 
"interests": [ "sports", “music” ] 
} 
} 
] 
} 
} 


中 


it} 


高 完 我 们 的 搜索 


很 多 程序 希望 能 在 搜索 结果 中 BH 匹配 到 的 关键 字 来 告诉 用 户 这 个 文档 是 如 何 匹配 他 们 的 
搜索 的 。 在 Elasticsearch 中 找到 高 亮片 段 是 非常 容易 的 。 


让 我 们 回 到 之 前 的 查询 ， 但 是 添加 一 个 highlight 参数 : 


GET /megacorp/employee/_sear 


{ 


ch 


hquery™ ka 
"match_phrase" : { 
"about" : "rock climbing" 
} 
} 
"highlight": { 
Bata NCS yams 
aboute (e) 
} 
} 


当 我 们 运行 这 个 查询 后 ， 相 同 的 命中 结果 会 被 返回 ， 但 是 我 们 会 得 到 一 个 新 的 名 叫 


highlight 的 部 分 。 在 这 里 包含 了 about 字段 中 的 匹配 单词 ， 并 且 会 被 <em></em> HTML 


FRERE: 


{ 
tS i 
“Eka a 
"max_score": 0.23013961, 
NSS 
{ 
"scoren: 07230139617 
"source": { 
“firstname: “Johni'; 
"last_name": smh 
tagel: 25, 
"about": "I love to go rock climbing", 
“interests: [ “sports, “music! | 
}, 
"highlight": { 
"about": [ 
"I love to go <em>rock</em> <em>climbing</em>" <i> 
] 
} 
} 
] 
} 
} 


1 在原 有 文本 中 高 亮 关键 字 。 


90 
到 过 


搜索 


30 


统计 


最 后 ， 我 们 还 有 一 个 需求 需要 完成 : 可 以 让 老板 在 职工 目录 中 进行 统计 。Elasticsearch 把 这 
项 功能 称 作 汇总 (aggregations)， 通 过 这 个 功能 ， 我 们 可 以 针对 你 的 数据 进行 复杂 的 统计 。 
这 个 功能 有 些 类 似 于 SQL 中 的 croup BY ， 但 是 要 比 它 更 加 强大 。 


例如 ， 让 我 们 找 一 下 员工 中 最 受 欢迎 的 兴趣 是 什么 : 


GET /megacorp/employee/_search 


{ 
"aggs": { 
"almterests i 
"terms": { "field": "interests" } 
} 
} 
} 


请 忽略 语法 ， 让 我 们 先 来 看 一 下 结果 : 


{ 
Mig e tap 
"aggregations": { 
“all_interests": { 
MDUCKeS call 
{ 
"key": "music", 
Ndocecount 2 
}, 
{ 
"key": “Forestry”, 
UdOCECOUNTE ee 
}, 
{ 
"key": “Sportsa, 
Kooye OUE l 
} 
] 
} 
} 
} 


我 们 可 以 发 现 有 两 个 员工 喜欢 音乐 ， 还 有 一 个 喜欢 森林 ， 还 有 一 个 喜欢 运动 。 这 些 数据 并 没 
有 被 预先 计算 好 ， 它 们 是 在 文档 被 查询 的 同时 实时 计算 得 出 的 。 如 果 你 想 要 查询 姓 Smith 的 
员工 的 兴趣 汇总 情况 ， 你 就 可 以 执行 如 下 查询 : 


GET /megacorp/employee/_search 


{ 
“query: 4 
"match": £{ 
"Tast name“: "smith" 
} 
}, 
"aggs": { 
"almnmterests {i 
"terms": { 
“ineld a InteresSESi 
} 
} 
} 
} 


这 样 ，all interests 的 统计 结果 就 只 会 包含 满足 查询 的 文档 了 : 


"all interests": { 


"buckets": [ 
{ 
"key": "music", 
doc Counti 2 
} 
{ 
“KEVA SPORES 
ddocaecounne :el 
} 


汇总 还 允许 多 个 层面 的 统计 。 比 如 我 们 还 可 以 统计 每 一 个 兴趣 下 的 平均 年 龄 : 


GET /megacorp/employee/_search 


{ 
"aggs" : { 
alenntenests Ba 
ECTS awe teld .Mterestseny 
a 
"avg_age" : { 
MEW) 8 af TITCTLO agen 
} 
} 
} 
} 


虽然 这 次 返回 的 汇总 结果 变 得 更 加 复杂 了 ， 但 是 它 依旧 很 容易 理解 : 


"all interests": { 
"buckets": [ 
{ 
Key "music", 
doc counta: 2; 
Vaviguagee: Ei 
"value"; 28.5 


} 
}, 
{ 
“key "forestry, 
vadocacounmt T 
Yavguage sf 
"value": 35 
} 
}, 
{ 
"key": "sports", 
"aocacount .1 
"avg_age": { 
"vyalue”: 25 
} 
} 


在 这 个 丰富 的 结果 中 ， 我 们 不 但 可 以 看 到 兴趣 的 统计 数据 ， 还 能 针对 不 同 的 兴趣 来 分 析 喜 欢 
这 个 兴趣 的 平均 年 龄 。 

即使 你 现在 还 不 能 很 好 地 理解 语法 ， 但 是 相信 你 还 是 能 发 现 ， 用 这 个 功能 来 实现 如 此 复杂 的 
统计 工作 是 这 样 的 简单 。 你 的 极限 取决 于 你 存 入 了 什么 样 的 数据 哟 |! 


小 结 


希望 上 面 的 几 个 小 教程 可 以 很 好 地 向 你 解释 Elasticsearch 可 以 实现 什么 功能 。 为 了 保持 教程 
简短 ， 这 里 只 提 及 了 一 些 基础 ， 除 此 之 外 还 有 很 多 功能 ， 比 如 建议 、 地 理 定 位 、 过 滤 、 模 糊 
以 及 部 分 匹配 等 。 但 是 相信 你 也 发 现 了 ， 在 这 里 你 只 需要 很 简单 的 操作 就 可 以 完成 复杂 的 操 
作 。 无 需 配 置 ， 添 加 数据 就 可 以 开始 搜索 ! 

可 能 前 面 有 一 些 语法 会 让 你 觉得 很 难 理解 ， 你 可 能 对 如 何 调整 优化 它们 还 有 很 多 疑问 。 那 


么 ， 本 书 之 后 的 章节 将 会 帮助 你 逐步 解 开 疑问 ， 让 你 对 Elasticsearch 是 如 何 工作 的 有 一 个 全 
面 的 了 解 。 


分 布 式 特性 


在 最 开始 的 章节 中 ， 我 们 曾经 提 到 Elasticsearch 可 以 被 扩展 到 上 百人 台 (HALTE) 服务 器 
上 ， 来 处 理 PB 级 别 的 数据 。 我 们 的 教程 只 提 及 了 如 何 使 用 它 ， 但 是 并 没有 提 及 到 服务 器 方面 
的 内 容 。Elasticsearch 是 自动 分 布 的 ， 它 在 设计 时 就 考虑 到 可 以 隐藏 分 布 操作 的 复杂 性 。 


Elasticsearch 的 分 布 式 部 分 很 简单 。 你 甚至 不 需要 关于 分 布 式 系统 的 任何 内 容 ， 比 如 分 片 、 
集群 、 发 现 等 成 堆 的 分 布 式 概念 。 你 可 能 在 你 的 笔记 本 中 运行 着 刚才 的 教程 ， 如 果 你 想 在 一 
个 拥有 100 个 节点 的 集群 中 运行 教程 ， 你 会 发 现 操作 是 完全 一 样 的 。 


Elasticsearch 很 努力 地 在 避免 复杂 的 分 布 式 系统 ， 很 多 操作 都 是 自动 完成 的 : 


。 可 以 将 你 的 文档 分 区 到 不 同 容 器 或 者 分 片 中 ， 这 些 文档 可 能 被 存在 一 个 节点 或 者 多 个 节 
点 。 


o 跨 节 点 平衡 集群 中 节点 间 的 索引 与 搜索 负载 。 

e 自动 复制 你 的 数据 以 提供 宛 余 副本 ， 防 止 硬件 错误 导致 数据 丢失 。 
© 自动 在 节点 之 间 路 由 ， 以 帮助 你 找到 你 想 要 的 数据 。 

© 无 颖 扩展 或 者 恢复 你 的 集群 。 


当 你 在 阅读 这 本 书 时 ， 你 会 发 现 到 有 关 Elasticsearch 的 分 布 式 特性 分 布 式 特性 的 补充 章节 。 
在 这 些 章节 中 你 会 了 解 到 如 何 扩展 集群 以 及 故障 转移 ( 《分 布 式 集群 》) ， 如 何 处 理 文档 存 
储 (《 分 布 式 文档 》) ， 如 何 执行 分 布 式 搜索 (《 分 布 式 搜索 》 ) 





这 一 部 分 不 是 必须 要 看 的 你 不 懂 它 们 也 能 正常 使 用 Elasticsearch。 但 是 帮助 你 更 加 全 面 
完整 地 了 解 Elasticsearch。 你 也 可 以 在 之 后 需要 的 时 候 再 回来 翻阅 它们 。 


by 
总 结 
到 目前 为 止 ， 你 应 该 已 经 知道 Elasticsearch 可 以 实现 哪些 功能 ， 入 门 上 手 是 非常 简单 的 。 只 
需要 最 少 的 知识 和 配置 就 可 以 开始 使 用 Elasticsearch 也 是 它 的 追求 。 学 习 Elasticsearch 最 
好 的 方法 就 是 开始 使 用 它 : 进行 的 检索 与 搜索 吧 | 

当然 ， 学 得 越 多 ， 你 的 生产 力 就 越 高 。 你 也 就 能 对 特定 的 内 容 进行 微调 ， 得 到 更 适合 你 的 结 
果 。 

之 后 的 章节 ， 我 们 将 会 引领 你 从 新 手 晋 级 到 专家 。 每 一 个 章节 都 会 解释 一 个 要 点 ， 同 时 我 们 
也 会 提供 专家 级 别 的 小 提示 。 如 果 你 只 是 刚刚 起 步 ， 这 些 提 示 可 能 并 不 是 很 适合 你 。 
Elasticsearch 会 在 一 开始 设置 很 多 合理 的 默认 值 。 你 可 以 在 需要 提升 性 能 的 时 候 再 重新 回顾 


它们 。 


集群 
补充 章节 


正如 前 文 提 到 的 ， 这 就 是 第 个 补充 的 章节 ， 这 里 会 介绍 Elasticsearch 如 何在 分 布 式 环境 中 运 
行 。 本 章 解 释 了 常用 术语 ， 比 如 集群 (cluster), 节点 (node) 以 及 分 片 (Sharaj， 以 及 如 何 横 
向 扩展 主机 ， 如 何 处 理 硬件 故障 。 


尽管 这 一 章 不 是 必 读 章节 一 一 你 可 以 完全 不 用 理会 分 片 ， 复 制 以 及 故障 恢复 就 能 长 时 间 使 用 
Elasticsearch。 你 可 以 先 跳 过 这 一 章节 ， 然 后 在 你 需要 的 时 候 再 回来 。 


你 可 以 随时 根据 你 的 需要 扩展 Elasticsearch 。 你 可 以 购买 配置 更 好 的 主机 (vertical scale or 
scaling up) 或 者 购买 更 多 的 主机 (horizontal scale or scaling out) 来 达到 扩展 的 目的 。 


硬件 越 强 大 ，Elasticsearch 运行 的 也 就 越 快 ， 但 是 重 直 扩展 (vertical scale) 方式 也 有 它 的 局 
Rio Bik As RAYA TH HA RK (horizontal scale) 方式 ， 在 集群 中 添加 更 多 的 节点 ， 这 样 
能 在 节点 之 间 分 配 负载 。 

对 于 大 多 数 数 据 库 来 说 ， 横 向 扩展 意味 着 你 的 程序 往往 需要 大 改 ， 以 充分 使 用 这 些 新 添加 的 
设备 。 相 比 而 言 ，Elasticsearch 自 带 分 布 式 功 能 : 他 知道 如 何 管理 多 个 节点 并 提供 高 可 用 
性 。 这 也 就 意味 着 你 的 程序 根本 不 需要 为 扩展 做 任何 事情 。 


在 这 一 章节 ， 我 们 将 要 探索 如 何 根据 你 的 需要 创建 你 的 集群 ， 节 点 以 及 分 片 ， 并 保障 硬件 故 
障 后 ， 你 的 数据 依旧 的 安全 。 


如 果 我 们 启用 一 个 既 没 有 数据 ， 也 没有 索引 的 单一 节点 ， 那 我 们 的 集群 看 起 来 就 像 是 这 样 


NODE 1 - ® MASTER 


CLUSTER 


节点 是 Elasticsearch 运行 中 的 实例 ， 而 集群 则 包含 一 个 或 多 个 具有 相同 cluster.name 的 
节点 ， 它 们 协同 工作 ， 共 享 数 据 ， 并 共同 分 担 工作 负荷 。 由 于 节点 是 从 属 集 群 的 ， 集 群 会 自 
我 重组 来 均匀 地 分 发 数据 。 


集群 中 的 一 个 节点 会 被 选 为 master 节点 ， 它 将 负责 管理 集群 范畴 的 变更 ， 例 如 创建 或 删除 索 
引 ， 添 加 节点 到 集群 或 从 集群 删除 节点 。master 节点 无 需 参 与 文档 层面 的 变更 和 搜索 ， 这 意 
味 着 仅 有 一 个 master 节点 并 不 会 因 流 量 增长 而 成 为 瓶颈 。 任 意 一 个 节点 都 可 以 成 为 master 
节点 。 我 们 例 举 的 集群 只 有 一 个 节点 ， 因 此 它 会 扮演 master 节点 的 角色 。 

作为 用 户 ， 我 们 可 以 访问 包括 master 节点 在 内 的 集群 中 的 任 一 节点 。 每 个 节点 都 知道 各 个 文 
档 的 位 置 ， 并 能 够 将 我 们 的 请 求 直接 转发 到 拥有 我 们 想 要 的 数据 的 节点 。 无 论 我 们 访问 的 是 
哪个 节点 ， 它 都 会 控制 从 拥有 数据 的 节点 收集 响应 的 过 程 ， 并 返回 给 客户 端 最 终 的 结果 。 这 
一 切 都 是 由 Elasticsearch 透明 管理 的 。 


集群 健康 


在 Elasticsearch 集群 中 可 以 监控 统计 很 多 信息 ， 其 中 最 重要 的 就 是 : 


health)。 它 的 status 有 green ` yellow ` red 三 种 ; 


GET /_cluster/health 


在 一 个 没有 索引 的 空 集群 中 ， 它 将 返回 如 下 信息 : 


"cluster_name": 
statusi: 

"timed_out": 
"number_of_nodes": 
"number_of_data_nodes": 


"active_primary_shards": 


"active_shards": 
"relocating_shards": 
"initializing_shards": 
"unassigned_shards": 


"elasticsearch", 
"green", <1> 
false, 


©O © © 00 F B 


1. status 是 我 们 最 应 该 关注 的 字段 。 


集群 健康 (cluster 


status 可 以 告诉 我 们 当前 集群 是 否 处 于 一 个 可 用 的 状态 。 三 种 颜色 分 别 代 表 : 


状态 意义 
green 所 有 主 分 片 和 从 分 片 都 可 用 
yellow 所 有 主 分 片 可 用 ， 但 存在 不 可 用 的 从 分 片 
red 存在 不 可 用 的 主要 分 片 


在 接 下 来 的 章节 ， 我 们 将 学 习 一 下 什么 是 主要 分 片 (primary shard) 和 从 分 片 (replica 
shard)， 并 说 明 这 些 状态 在 实际 环境 中 的 意义 。 


添加 索引 


为 了 将 数据 添加 到 Elasticsearch， 我 们 需要 索引 (index) 一 一 存储 关联 数据 的 地 方 。 实 际 
Lo IREA 逻辑 命名 空间 (logical namespace)， 它 指向 一 个 或 多 个 分 片 (shards) 。 


TA (shard) 是 工作 单元 (worker unit) 底层 的 一 员 ， 它 只 负责 保存 索引 中 所 有 数据 的 一 小 
片 。 在 接 下 来 的 《深入 分 片 》 一 章 中 ， 我 们 还 将 深入 学 习 分 片 是 如 何 运 作 的 ， 但 是 现在 你 只 
要 知道 分 片 是 一 个 独立 的 Lucene 实 例 既 可 ， 并 且 它 自身 也 是 一 个 完整 的 搜索 引擎 。 我 们 的 文 
档 存 储 并 且 被 索引 在 分 片 中 ， 但 是 我 们 的 程序 并 不 会 直接 与 它们 通信 。 取 而 代 之 ， 它 们 直接 
与 索引 进行 通信 的 。 


在 elasticsearch 中 ， 分 片 用 来 分 配 集群 中 的 数据 。 把 分 片 想象 成 一 个 数据 的 容器 。 数 据 被 存 
储 在 分 片 中 ， 然 后 分 片 又 被 分 配 在 集群 的 节点 上 。 当 你 的 集群 扩展 或 者 缩小 时 ，elasticsearch 
会 自动 的 在 节点 之 间 迁 移 分 配 分 片 ， 以 便 集 群 保持 均衡 。 
分 片 分 为 主 分 片 (primary shard) 以 及 从 分 片 (replica shard) 两 种 。 在 你 的 索引 中 ， 每 一 个 
文档 都 属于 一 个 主 分 片 ， 所 以 具体 有 多 少 主 分 片 取决 于 你 的 索引 能 存储 多 少数 据 。 
虽然 理论 上 主 分 片 对 存储 多 少数 据 是 没有 限制 的 。 分 片 的 最 大 数量 完全 取决 于 你 的 实际 
状况 : 硬件 的 配置 、 文 档 的 大 小 和 复杂 度 、 如 何 索 引 和 查询 你 的 文档 ， 以 及 你 期 望 的 响 
应 时 间 。 
从 分 片 只 是 主 分 片 的 一 个 副本 ， 它 用 于 提供 数据 的 宛 余 副本 ， 在 硬件 故障 时 提供 数据 保护 ， 
同时 服务 于 搜索 和 检索 这 种 只 读 请 求 。 


索引 中 的 主 分 片 的 数量 在 索引 创建 后 就 固定 下 来 了 ， 但 是 从 分 片 的 数量 可 以 随时 改变 。 


接 下 来 ， 我 们 在 空 的 单 节点 集群 中 上 创建 一 个 叫做 blogs 的 索引 。 一 个 索引 默认 设置 了 5 个 
主 分 片 ， 但 是 为 了 演示 ， 我 们 这 里 只 设置 3 个 主 分 片 和 一 组 从 分 片 (每 个 主 分 片 有 一 个 从 分 片 
对 应 ) 


PUT /blogs 
{ 

MS Citta Siem es 
"number_of_shards" : 3, 
"number_of_replicas" : 1 

} 

} 


现在 ， 我 们 的 集群 看 起 来 就 像 下 图 所 示 了 有 索引 的 单 节 点 集群 ， 这 三 个 主 分 片 都 被 分 配 在 


Node 1 ° 


NODE 1 - ® MASTER 


CLUSTER 





如 果 我 们 现在 查看 集群 健康 (cluster-health) ， 我 们 将 得 到 如 下 信息 : 


"cluster_name": “elasticsearch", 
“Stacusu: "yellow", <1> 
"timed_out": false, 
"number_of_nodes": 
"number_of_data_nodes": 
"active_primary_shards": 


~ 


"relocating_shards": 


~ 


"initializing_shards": 


~ 


1 
1 
3 
"active_shards": 3 
0 
0 
3 


"unassigned_shards": <2> 


1. 集群 的 Status ‘i yellow . 
2. 我 们 的 三 个 从 分 片 还 没有 被 分 配 到 节点 上 。 


集群 的 健康 状况 yellow 意味 着 所 有 的 主 分 片 (primary shards) 启动 并 且 运 行 了 3 了， 这 时 集群 
已 经 可 以 成 功 的 处 理 任意 请 求 ， 但 是 从 分 片 (replica shards) 没有 完全 被 激活 。 事 实 上 ， 当 
前 这 三 个 从 分 片 都 处 于 unassigned (未 分 配 ) 的 状态 ， 它 们 还 未 被 分 配 到 节点 上 。 在 同一 个 
节点 上 保存 相同 的 数据 副本 是 没有 必要 的 ， 如 果 这 个 节点 故障 了 ， 就 等 同 于 所 有 的 数据 副本 
也 丢失 了 。 


现在 我 们 的 集群 已 经 可 用 了 ， 但 是 依旧 存在 因 硬 件 故障 而 导致 数据 丢失 的 风险 。 


增加 故障 转移 


在 单一 节点 上 运行 意味 着 有 单 点 故障 的 风险 ， 没 有 数据 宛 余 备 份 。 幸 运 的 是 ， 我 们 可 以 启用 
另 一 个 节点 来 保护 我 们 的 数据 。 


启动 第 二 个 节点 


为 了 测试 在 增加 第 二 个 节点 后 发 生 了 什么 ， 你 可 以 使 用 与 第 一 个 节点 相同 的 方式 启动 第 二 个 
节点 (你 可 以 参考 入 门 -》 安 装 -》 运 行 Elasticsearch 一 章 ) ， 而 且 在 同一 个 目录 一 一 多 个 节 
点 可 以 分 享 同一 个 目录 。 


只 要 第 二 个 节点 与 第 一 个 节点 的 cluster.name 相同 (参见 ./config/elasticsearch.yml 文件 
中 的 配置 ) ， 它 就 能 自动 发 现 并 加 入 到 第 一 个 节点 的 集群 中 。 如 果 没有 ， 请 结合 日 志 找 出 问 
题 所 在 。 这 可 能 是 多 播 (multicast) 被 禁用 ， 或 者 防火 墙 阻止 了 节点 间 的 通信 


o 


如 果 我 们 启动 了 第 二 个 节点 ， 这 个 集群 应 该 叫做 双 节 点 集群 (cluster-two-nodes) 


节点 集群 一 一 所 有 的 主 分 片 和 从 分 片 都 被 分 配 : 


NODE 1 - ® MASTER NODE 2 


CLUSTER 





当 第 二 个 节点 加 入 后 ， 就 产生 了 三 个 从 分 片 (replica shards) ， 它 们 分 别 于 三 个 主 分 片 一 一 
对 应 。 也 就 意味 着 即使 有 一 个 节点 发 生 了 损坏 ， 我 们 可 以 保证 数据 的 完整 性 


所 有 被 索引 的 新 文档 都 会 先 被 存储 在 主 分 片 中 ， 之 后 才 会 被 平行 复制 到 关联 的 从 分 片上 。 
样 可 以 确保 我 们 的 文档 在 主 节 点 和 从 节点 上 都 能 被 检索 。 


当前 ， cluster-health 的 状态 为 green ， 这 意味 着 所 有 的 6 个 分 片 (= 三 个 主 分 片 和 三 个 从 分 
H) 都 已 激活 : 


"cluster_name": "elasticsearch", 
"status": "green", <i> 
"timed_out": false, 


"number_of_nodes": 
"number_of_data_nodes": 
"active_primary_shards": 
"active_shards": 
"relocating_shards": 
"initializing_shards": 
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"unassigned_shards": 


1. 集群 的 status 是 green . 


我 们 的 集群 不 仅 功 能 齐全 的 ， 并 且 具 有 高 可 用 性 。 


横向 扩展 


随 着 应 用 需求 的 增长 ， 我 们 该 如 何 扩展 ? 如 果 我 们 启动 第 三 个 ， 集群 内 会 自动 重组 ， 这 
时 便 成 为 了 三 节点 集群 (cluster-three-nodes) 


分 片 已 经 被 重新 分 配 以 平衡 负载 : 


NODE 1 - ® MASTER 


CLUSTER 


= 





在 Node 1 和 Node 2 中 分 别 会 有 一 个 分 片 被 移动 到 Node 3 上 ， 这 样 一 来 ， pE 
都 只 有 两 个 分 片 了 。 这 意味 着 每 个 节点 的 硬件 资源 (CPU ` RAM `O) 被 更 少 的 分 片 共 
所 以 每 个 分 片 就 会 有 更 好 的 性 能 表现 。 


分 片 本 身 就 是 一 个 非常 成 熟 的 搜索 引擎 ， 它 可 以 使 用 单个 节点 的 所 有 资源 。 我 们 一 共有 6 个 分 
A (3 个 主 分 片 和 3 个 从 分 片 ) ， 因 此 最 多 可 以 扩展 到 6 个 节点 ， 每 个 节点 上 有 一 个 分 片 ， 这 样 
每 个 分 片 都 可 以 使 用 到 所 在 节点 100% 的 资源 了 。 


扩展 更 多 


但 是 如 果 我 们 想 要 扩展 到 六 个 节点 以 上 应 该 怎么 办 ? 


主 分 片 的 数量 在 索引 创建 的 时 候 就 已 经 指定 了 ， 实 际 上 ， 这 个 数字 定义 了 能 存储 到 索引 中 的 
数据 最 大 量 (具体 的 数量 取决 于 你 的 数据 ， 硬 件 的 使 用 情况 ) 。 例 如 ， 读 请 求 一 一 搜索 或 者 
文档 恢复 就 可 以 由 主 分 片 或 者 从 分 片 来 执行 ， 所 以 当 你 拥有 更 多 份 数据 的 时 候 ， 你 就 拥有 了 
更 大 的 吞吐 量 。 





从 分 片 的 数量 可 以 在 运行 的 集群 中 动态 的 调整 ， 这 样 我 们 就 可 以 根据 实际 需求 扩展 或 者 缩小 
规模 。 接 下 来 ， 我 们 来 增加 一 下 从 分 片 组 的 数量 : 


PUT /blogs/_settings 
{ 


"number_of_replicas" : 2 


} 


增加 number_of_replicas 到 2 : 


NODE 1 - ® MASTER NODE 2 NODE 3 


CLUSTER 





从 图 中 可 以 看 出 ， 现 在 blogs 的 索引 总 共有 9 个 分 片 : 3 个 主 分 片 和 6 个 从 分 片 。 也 就 是 说 ， 
现在 我 们 就 可 以 将 总 节点 数 扩展 到 9 个 ， 就 又 会 变 成 一 个 节点 一 个 分 片 的 状态 了 。 最 终 我 们 得 
到 了 三 倍 搜索 性 能 的 三 节点 集群 。 


提示 
当然 ， 仅 仅 是 在 同样 数量 的 节点 上 增加 从 分 片 的 数量 是 根本 不 能 提高 性 能 的 ， 因 为 每 个 分 片 
都 有 访问 系统 资源 的 权限 。 你 需要 升级 硬件 配置 以 提高 吞吐 量 。 


不 过 更 多 的 从 分 片 意味 着 我 们 有 更 多 的 完 余 : 通过 上 文 的 配置 ， 我 们 可 以 承受 两 个 节点 的 故 
障 而 不 会 丢失 数据 。 


扩展 
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2 = 
故障 恢复 
前 文 我 们 已 经 提 到 过 Elasticsearch 可 以 应 对 节点 故障 。 让 我 们 来 尝试 一 下 。 如 果 我 们 把 第 一 


个 节点 杀 掉 ， 我 们 的 集群 就 会 如 下 图 所 示 : 


NODE 2 - *# MASTER NODE 3 


CLUSTER 





被 杀 掉 的 节点 是 主 节点 。 而 为 了 集群 的 正常 工作 必须 需要 一 个 主 节点 ， 所 以 首先 进行 的 进程 
就 是 从 各 节点 中 选择 了 一 个 新 的 主 节点 : Node 2 。 


主 分 片 1 和 2 在 我 们 杀 掉 Node 1 后 就 丢失 了 ， 我 们 的 索引 在 丢失 主 节点 的 时 候 是 不 能 
正常 工作 的 。 如 果 我 们 在 这 个 时 候 检查 集群 健康 状态 ， 将 会 显示 red : 存在 不 可 用 的 主 节 


INN 。 


幸运 的 是 ， 丢 失 的 两 个 主 分 片 的 完整 拷贝 在 存在 于 其 他 的 节点 上 ， 所 以 新 的 主 节点 所 完成 的 
第 一 件 事 情 就 是 将 这 些 在 Node 2 和 Node 3 上 的 从 分 片 提升 为 主 分 片 ， 然 后 集群 的 健康 状 
态 就 变 回 至 yellow 。 这 个 提升 的 进程 是 瞬间 完成 了 ， 就 好 像 按 了 一 下 开关 。 


那么 为 什么 集群 健康 状态 依然 是 是 yellow 而 不 是 green 呢 ? 是 因为 现在 我 们 有 3 个 主 分 
片 ， 但 是 我 们 之 前 设 定 了 1 个 主 分 片 有 2 个 从 分 片 ， 但 是 现在 却 只 有 1 份 从 分 片 ， 所 以 状态 无 法 
EA green ， 不 过 我 们 可 以 不 用 太 担 心 这 里 : 当 我 们 再 次 杀 掉 Node 2 的 时 候 ， 我 们 的 程序 
依旧 可 以 在 没有 丢失 任何 数据 的 情况 下 运行 ， 因 为 Node 3 中 依 昌 拥有 每 个 分 片 的 备份 。 


如 果 我 们 重启 Node 1 ， 集 群 就 能 够 重新 分 配 丢 失 的 从 分 片 ， 这 样 结果 就 会 与 三 节点 两 从 集群 
一 致 。 如 果 node 1 依旧 还 有 旧 节 点 的 内 容 ， 系 统 会 尝试 重新 利用 他 们 ， 并 只 会 复制 在 故障 
期 间 的 变更 数据 。 


到 目前 为 止 ， 我 们 已 经 清晰 地 了 解 了 Elasticsearch 的 横向 扩展 以 及 数据 安全 的 相关 内 容 。 接 
下 来 ， 我 们 将 要 继续 讨论 分 片 的 生命 周期 等 更 多 细节 。 


索引 一 个 文档 


文档 通过 索引 API 被 索引 一 存储 并 使 其 可 搜索 。 但 是 最 开始 我 们 需要 决定 我 们 将 文档 存储 
在 哪里 。 正 如 之 前 提 到 的 ， 一 篇 文档 通过 _index , _type UR _id 来 确定 它 的 唯一 性 。 我 们 
可 以 自己 提供 一 个 id ， 或 者 也 使 用 index API 帮 我 们 生成 一 个 。 


使 用 目 己 的 ID 


如 果 你 的 文档 拥有 天 然 的 标示 符 (例如 user_account 字段 或 者 文档 中 其 他 的 标识 值 ) ， 这 时 
你 就 可 以 提供 你 自己 的 .id ， 这 样 使 用 index API : 


PUT /{index}/{type}/{id} 
{ 


"field": "value", 


几 个 例子 。 如 果 我 们 的 索引 叫做 "website" ， 我 们 的 类 型 叫做 "blog" ， 然 后 我 们 选 
择 "123" 作为 ID 的 编号 。 这 时 ， 请 求 就 是 这 样 的 : 


PUT /website/blog/1i23 


{ 
“titlet: “My first blog entry, 
ext ESE EVENE] EES OUE a ay 
“date”: "2014/01/01" 

} 


De 。 


Elasticsearch 返 回 内 容 : 


{ 
"index": "website", 
" type”: 加 上 下 OO 
eso jabs T2307 
"version": 1, 
"created": true 

} 


这 个 返回 值 意味 着 我 们 的 索引 请 求 已 经 被 成 功 创建 ， 其 中 还 包含 了 Lindex, _type 以 
及 id 的 元 数据 ， 以 及 一 个 新 的 元 素 version ° 


在 Elasticsearch 中 ， 每 一 个 文档 都 有 一 个 版 本 号 码 。 每 当 文 档 产生 变化 时 (包括 删 
R) > version 就 会 增 大 。 在 《版 本 控制 》 中 ， 我 们 将 会 详细 讲解 如 何 使 用 _version 的 数 
字 来 确认 你 的 程序 不 会 随意 替换 掉 不 想 履 盖 的 数据 。 


自 增 1D 
如 果 我 们 的 数据 中 没有 天 然 的 标示 符 ， 我 们 可 以 让 Elasticsearch 为 我 们 自动 生成 一 个 。 请 求 
的 结构 发 生 了 变化 : 我 们 把 PUT 一 一 “把 文档 存储 在 这 个 地 址 中 ”变量 变 成 了 post 一 一 “把 文 


档 存储 在 这 个 地 址 下 ”。 


这 样 一 来 ， 请 求 中 就 只 包含 index 和 _type 了 : 


POST /website/blog/ 


{ 
Stites My Second: plogeentiny., 
ECX wes CMe Vae Ens ou 
“daten: 12014/701/018 


这 次 的 反馈 和 之 前 基本 一 样 ， 只 有 _id 改 成 了 系统 生成 的 自 增值 : 


{ 
"index": "website", 
"type": "blog", 
eal clin "wMOOSFhHDQXGZAWDFO-drSA", 
"version": 1, 
"created": true 
} 


自生 成 ID 是 由 22 个 字母 组 成 的 ， 安 全 universally unique identifiers 或 者 被 称 为 UUIDs。 


文档 是 什么 ? 


在 很 多 程序 中 ， 大 部 分 实体 或 者 对 象 都 被 序列 化 为 包含 键 和 值 的 JSON 对 象 。 键 是 一 个 字段 或 
者 属性 的 名 字 ， 值 可 以 是 一 个 字符 串 、 数 字 、 布 尔 值 、 对象、 数组 或 者 是 其 他 的 特殊 类 型 ， 
比如 代表 日 期 的 字符 串 或 者 代表 地 理 位 置 的 对 象 : 


{ 
"name": WJohnnesSmatiie, 
"age": 42, 
"confirmed": true, 
"join_date": "2014-06-01", 
"home": { 
slati: SRS, 
MNOME: (ole al 
}, 
accounts lh 
{ 
"type": "facebook", 
wale |e "jJohnsmith" 
}, 
{ 
"type: "twitter", 
wale |e "jJohnsmith" 
} 
] 
} 


通常 情况 下 ， 我 们 使 用 可 以 互 换 对 象 和 文档 。 然 而 ， 还 是 有 一 个 区 别 的 。 对 象 (object ) 仅 仅 是 
一 个 JSON 对 象 , 类 似 于 哈 硕 ， 哈 希 上 映射， 字典 或 关联 数组 。 对 象 (Objects) 则 可 以 包含 其 他 对 
% (Objects) ° 

在 Elasticsearch 中 ， 文 档 这 个 单词 有 特殊 的 含义 。 它 指 的 是 在 Elasticsearch 中 被 存储 到 唯一 ID 
下 的 由 最 高 级 或 者 根 对 象 (root object ) 序 列 化 而 来 的 JSON。 


文档 元 数据 


一 个 文档 不 只 包含 了 数据 。 它 还 包含 了 元 数据 (metadata) 一 一 关于 文档 的 信息 。 有 三 个 元 数 
据 元 素 是 必须 存在 的 ， 它 们 是 : 


RF 说 明 


_index 文档 存储 的 地 方 

_type 文档 代表 的 对 象 种 类 

_id 文档 的 唯一 编号 
_index 


索引 类 似 于 传统 数据 库 中 的 "数据 库 " 也 就 是 我 们 存储 并 且 索 引 相 关 数 据 的 地 方 。 


TIP : 


在 Elasticsearch 中 ， 我 们 的 数据 都 在 分 片 中 被 存储 以 及 索引 ， 索 引 只 是 一 个 逻辑 命名 空间 ， 
它 可 以 将 一 个 或 多 个 分 片 组 合 在 一 起 。 然 而 ， 这 只 是 一 个 内 部 的 运作 原理 ”我们 的 程序 可 
以 根本 不 用 关心 分 片 。 对 于 我 们 的 程序 来 说 ， 我 们 的 文档 存储 在 索引 中 。 剩 下 的 交 给 
Elasticsearch 就 可 以 了 。 


我 们 将 会 在 《索引 管理 》 章 节 中 探讨 如 何 创建 并 管理 索引 。 但 是 现在 ， 我 们 只 需要 证 
Elasticsearch 帮 助 我 们 创建 索引 。 我 们 只 需要 选择 一 个 索引 的 名 字 。 这 个 名 称 必 须要 全 部 小 
写 ， 也 不 能 以 下 划 线 开头 ， 不 能 包含 过 号 。 我 们 可 以 用 website 作为 我 们 索引 的 名 字 。 


_type 


在 程序 中 ， 我 们 使 用 对 象 代表 “物品 *， 比 如 一 个 用 户 、 一 篇 博文 、 一 条 留言 或 者 一 个 邮件 。 每 
一 个 对 象 都 属于 一 种 类 型 ， 类 型 定义 了 对 象 的 属性 或 者 与 数据 的 关联 。 用 户 类 的 对 象 可 能 就 
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在 传统 的 数据 库 中 ， 我 们 总 是 将 同类 的 数据 存储 在 同一 个 表 中 ， 因 为 它们 的 数据 格式 是 相同 
的 。 同 理 ， 在 Elasticsearch 中 ， 我 们 使 用 同样 类 型 的 文档 来 代表 同类 "事物 ”"， 也 是 因为 它们 的 
数据 结构 是 相同 的 。 


每 一 个 类 型 都 拥有 自己 的 映射 (mapping) 或 者 结构 定义 ， 它 们 定义 了 当前 类 型 下 的 数据 结构 ， 
类 似 于 数据 库 表 中 的 列 。 所 有 类 型 下 的 文档 会 被 存储 在 同一 个 索引 下 ， 但 是 映射 会 告诉 
Elasticsearch 不 同 的 数据 应 该 如 何 被 索引 。 

我 们 将 会 在 《上 映射》 中 探讨 如 何 制定 或 者 管理 映射 ， 但 是 目前 为 止 ， 我 们 只 需要 依靠 
Elasticsearch 来 自动 处 理 数据 结构 。 


_id 
jd 是 一 个 字符 串 ， 当 它 与 index 以 及 _type 组 合 时 ， 就 可 以 来 代表 Elasticsearch 中 一 个 特定 


的 文档 。 我 们 创建 了 一 个 新 的 文档 时 ， 你 可 以 自己 提供 一 个 _id ， 或 者 也 可 以 让 
Elasticsearch 帮 你 生成 一 个 。 


其 他 元 数据 


在 文档 中 还 有 一 些 其 他 的 元 数据 ， 我 们 将 会 在 《上 映射》 章节 中 详细 讲解 。 使 用 上 面 罗 列 的 元 
素 ， 我 们 已 经 可 以 在 Elasticsearch 中 存储 文档 或 者 通过 ID 来 搜索 已 经 保存 的 文档 了 。 


搜索 文档 


要 从 Elasticsearch 中 获取 文档， 我 们 需要 使 用 同样 的 _index ， _type 以 及 _id 但 是 不 同 的 
HTTP 变 量 GET 


GET /website/blog/i23?pretty 


返回 结果 包含 了 之 前 提 到 的 内 容 ， 以 及 一 个 新 的 字段 source ， 它 包含 我 们 在 最 初创 建 索引 
时 的 原始 JSON 文 档 。 


{ 
ndex : "website", 
“typet: lo loYo ee 
wc Te 
J VenrsLon : 1, 
found MT: true, 
WE SOUTEG Clue 作 
Stites My lps bloogentr ye 
ext Just Eryingn Chas ou 
"date": "2014/01/01" 
} 
} 
pretty 


在 任意 的 查询 字符 串 中 添加 pretty 参数 ， 类 似 上 面 的 请 求 ，Elasticsearch 就 可 以 得 到 优美 打 
印 的 更 加 易于 识别 的 JSON 结 果 。 _source 字段 不 会 执行 优美 打印 ， 它 的 样子 取决 于 我 们 录入 
的 样子 。 


GET 请 求 的 返回 结果 中 包含 "found": true} 。 这 意味 着 这 篇 文档 确实 被 找到 了 。 如 果 我 们 请 
求 了 一 个 不 存在 的 文档 ， 我 们 依然 会 得 到 JSON 反 馈 ， 只 是 found 的 值 会 变 为 false ° 


同样 ，HTTP 和 返回 码 也 会 由 '200 0K' BA '404 Not Found' 。 我 们 可 以 在 curl 后 添加 -i ， 
这 样 你 就 能 得 到 反馈 头 文件 : 


curl -i -XGET /website/blog/i24?pretty 


反馈 结果 就 会 是 这 个 样子 : 


HTTP/1.1 404 Not Found 
Content-Type: application/json; charset=UTF-8 
Content-Length: 83 


{ 
" index" : "website", 
“typet k log 
aidui: ETZAN 
"found" : false 

} 


检索 文档 中 的 一 部 分 


通常 ， GET 请 求 会 将 整个 文档 放 入 source 字段 中 一 并 返回 。 但 是 可 能 你 只 需要 title F 
段 。 你 可 以 使 用 _source 得 到 指定 字段 。 如 果 需 要 多 个 字段 你 可 以 使 用 过 号 分 隔 : 


GET /website/blog/123?_source=title, text 


现在 source 字段 中 就 只 会 显示 你 指定 的 字段 : 


{ 
"_index" : "website", 
"type" +: “blog”, 
Tale! size, 
“versione : 1, 
"exists" : true, 
"sourcen: { 
stit lete EMY furnse blogmenery y 
MEESE HISE AE ES ou 
} 
} 


或 者 你 只 想得到 _source 字段 而 不 要 其 他 的 元 数据 ， 你 可 以 这 样 请 求 : 


GET /website/blog/123/_source 


这 样 结果 就 只 返回 : 
{ 
“title”: "My first bilog entry", 
EX ee US tatarayall Ole ENIS OU e, 
“daten: "20114701//01" 


Get 
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检查 文档 是 否 存 在 


如 果 确 实 想 检查 一 下 文档 是 否 存 在 ， 你 可 以 试用 HEAD 来 替代 GET 方法 ， 这 样 就 是 会 返回 
HTTP 头 文件 : 


curl -i -XHEAD /website/blog/123 


如 果 文 档 存 在 ，Elasticsearch 将 会 返回 200 ok 的 状态 码 : 


HTTP/1.1 200 OK 
Content-Type: text/plain; charset=UTF-8 
Content-Length: 0 


如 果 不 存 在 将 会 返回 404 Not Found KA: 


curl -i -XHEAD /website/blog/124 


HTTP/1.1 404 Not Found 
Content-Type: text/plain; charset=UTF-8 
Content-Length: 0 


当然 ， 这 个 反馈 只 代表 了 你 查询 的 那 一 刻 文档 不 存在 ， 但 是 不 代表 几 毫 秒 后 它 不 存在 ， 很 可 
能 与 此 同时 ， 另 一 个 进程 正在 创建 文档 。 


更 新 整个 文档 


在 Documents 中 的 文档 是 不 可 改变 的 。 所 以 如 果 我 们 需要 改变 已 经 存在 的 文档 ， 我 们 可 以 使 
用 《索引 》 中 提 到 的 index API 来 重新 索引 或 者 替换 掉 它 : 


PUT /website/blog/123 

{ 
Heateo EAEN 
"text": "I am starting to get the hang of this...", 
“date”: "2014/01/02" 


在 反馈 中 ， 我 们 可 以 发 现 Elasticsearch 已 经 将 version 数值 增加 了 : 


{ 
w indexi: "website", 
“itype: “blog; 
WT io ea 2 
"version" : 2, 
"created": false <1> 
} 


1. created 被 标记 为 false 是 因为 在 同 索引 ss ie 类 型 下 已 经 存在 同 ID 的 文档 2 


在 内 部 ，Elasticsearch 已 经 将 昌文 档 标记 为 删除 并 且 添 如 了 新 的 文档 。 昌 的 文档 并 不 会 立即 
消失 ， 但 是 你 也 无 法 访问 他 。Elasticsearch 会 在 你 继续 添加 更 多 数据 的 时 候 在 后 台 清 理 已 经 
删除 的 文件 。 


在 本 章 的 后 面 ， 我 们 将 会 在 《局 部 更 新 》 中 介绍 最 新 更 新 的 APIl。 这 个 API 人 允许 你 修改 局 部 ， 
但 是 原理 和 下 方 的 完全 一 样 : 


从 昌 的 文档 中 检索 JSON 
修改 它 

删除 修 的 文档 
索引 一 个 新 的 文档 


FwNnN > 


唯一 不 同 的 是 ， 使 用 了 update API 你 就 不 需要 使 用 get 然后 再 操作 index HRT ° 


创建 一 个 文档 


当 我 们 索引 一 个 文档 时 ， 如 何 确定 我 们 是 创建 了 一 个 新 的 文档 还 是 覆盖 了 一 个 已 经 存在 的 文 
档 呢 ? 


请 牢记 _index , _type UR _id 组 成 了 唯一 的 文档 标记 ， 所 以 为 了 确定 我 们 创建 的 是 全 新 的 
内 容 ， 最 简单 的 方法 就 是 使 用 post 方法 ， 让 Elasticsearch 自 动 创建 不 同 的 id 


POST /website/blog/ 
人 


然而 ， 我 们 可 能 已 经 决定 好 了 id ， 所 以 需要 告诉 Elasticsearch 只 有 当 _index ， _type 以 
及 id 这 3 个 属性 全 部 相同 的 文档 不 存在 时 才 接 受 我 们 的 请 求 。 实 现 这 个 目的 有 两 种 方法 ， 他 
们 实质 上 是 一 样 的 ， 你 可 以 选择 你 认为 方便 的 那 种 : 


第 一 种 是 在 查询 中 添加 op_type 参数 : 


PUT /website/blog/123?0p_type=create 
小 


或 者 在 请 求 最 后 添加 /_create : 


PUT /website/blog/1i23/_create 
tbo i 


如 果 成 功 创建 了 新 的 文档 ，Elasticsearch 将 会 返回 常见 的 元 数据 以 及 201 created 的 HTTP 反 


馈 码 。 


而 如 果 存 在 同名 文件 ，Elasticsearch 将 会 返回 一 个 409 conflict 的 HTTP 反 馈 码 ， 以 及 如 下 方 
的 错误 信息 : 


{ 
"error" : "DocumentAlreadyExistsException[[website][4] [blog][123]: 
document already exists]", 
"status" : 409 


删除 一 个 文档 
删除 文档 的 基本 模式 和 之 前 的 基本 一 样 ， 只 不 过 是 需要 更 换 成 DELETE 方法 : 


DELETE /website/blog/1i23 


如 果 文 档 存 在 ， 那 么 Elasticsearch 就 会 返回 一 个 200 ok 的 HTTP 响 应 码 ， 返 回 的 结果 就 会 像 
下 面 展示 的 一 样 。 请 注意 version 的 数字 已 经 增加 了 。 


{ 
"found" : enue, 
"index" : "website", 
w type" +: "blog", 
lo le 
Verslom : 3 

} 


如 果 文 档 不 存在 ， 那 么 我 们 就 会 得 到 一 个 404 Not Found 的 响应 码 ， 返 回 的 内 容 就 会 是 这 样 
ay: 


{ 
"found" : false, 
"_index" : "website", 
“ type" x Mibllocu: 
dealt bd 3 Uae yl 
"_version" : 4 
} 
尽管 文档 并 不 存在 ( "found" 424A false ) ? 但 是 _version 的 数值 仍然 增加 了 。 | 个 就 是 内 
部 管理 的 一 部 分 ， 它 保证 了 我 们 在 多 个 节点 间 的 不 同 操作 的 顺序 都 被 正确 标记 了 © 


正如 我 在 《更 新 》 一 章 中 提 到 的 ， 删 除 一 个 文档 也 不 会 立即 生效 ， 它 只 是 被 标记 成 已 删除 。 
Elasticsearch 将 会 在 你 之 后 添加 更 多 索引 的 时 候 才 会 在 后 台 进 行 删除 内 容 的 清理 。 


处 理 冲 突 


当 你 使 用 索引 API 来 更 新 一 个 文档 时 ， 我 们 先 看 到 了 原始 文档 ， 然 后 修改 它 ， 最 后 一 次 性 地 
将 整个 新 文档 进行 再 次 索引 处 理 。Elasticsearch 会 根据 请 求 发 出 的 顺序 来 选择 出 最 新 的 一 个 
文档 进行 保存 。 但 是 ， 如 果 在 你 修改 文档 的 同时 其 他 人 也 发 出 了 指令 ， 那 么 他 们 的 修改 将 会 
FR e 


很 长 时 间 以 来 ， 这 其 实 都 不 是 什么 大 问题 。 或 许 我 们 的 主要 数据 还 是 存储 在 一 个 关系 数据 库 
中 ， 而 我 们 只 是 将 为 了 可 以 搜索 ， 才 将 这 些 数据 拷贝 到 Elasticsearch 中 。 或 许 发 生 多 个 人 同 
时 修改 一 个 文件 的 概率 很 小 ， 又 或 者 这 些 偶然 的 数据 丢失 并 不 会 影响 到 我 们 的 正常 使 用 。 


但 是 有 些 时 候 如 果 我 们 丢失 了 数据 就 会 出 大 问题 。 想 象 一 如 果 我 们 使 用 Elasticsearch 来 
存储 一 个 网 店 的 商品 数量 。 每 当 我 们 卖 出 一 件 ， 我 们 就 会 将 这 个 数量 减少 一 个 。 


突然 有 一 和 天， 老板 决定 来 个 大 促销 。 有 瞬间 ， 每 秒 就 产生 了 多 笔 交 易 。 并 行 处 理 ， 多 个 进程 来 
处 理 交易 : 


版 本 控制 





CC Cox 
Web-1 . Web-2 





(x 


web_1 中 库存 量 的 变化 丢失 的 原因 是 web_2 并 不 知道 它 所 得 到 的 库存 量 数据 是 是 过 期 的 。 
样 就 会 导致 我 们 误 认为 还 有 很 多 货 存 ， 最 终 顾 客 就 会 对 我 们 的 行为 感到 失望 。 


当 我 们 对 数据 修改 得 越 频繁 ， 或 者 在 读 取 和 更 新 数据 间 有 越 长 的 空 亲 时间， 我们 就 越 容 易 丢 
失掉 我 们 的 数据 。 


以 下 是 两 种 能 避免 在 并 发 更 新 时 丢失 数据 的 方法 : 


REM FF RAE Hl (PCC) 


这 一 点 在 关系 数据 库 中 被 广泛 使 用 。 假 设 这 种 情况 很 容易 发 生 ， 我 们 就 可 以 阻止 对 这 一 资源 
的 访问 。 典 型 的 例子 就 是 当 我 们 在 读 取 一 个 数据 前 先 锁定 这 一 行 ， 然 后 确保 只 有 读 取 到 数据 
的 这 个 线程 可 以 修改 这 一 行 数据 。 


乐观 并 发 控制 (OCC) 


Elasticsearch 所 使 用 的 。 假 设 这 种 情况 并 不 会 经 常 发 生 ， 也 不 会 去 阻止 某 一 数据 的 访问 。 然 
而 ， 如 果 基 础 数据 在 我 们 读 取 和 写 入 的 间隔 中 发 生 了 变化 ， 更 新 就 会 失败 。 这 时 候 就 由 程序 
来 决定 如 何 处 理 这 个 冲突 。 例 如 ， 它 可 以 重新 读 取 新 数据 来 进行 更 新 ， 又 或 者 它 可 以 将 这 一 
情况 直接 反馈 给 用 户 。 


乐观 并 发 控制 


Elasticsearch 是 分 布 式 的 。 当 文档 被 创建 、 更 新 或 者 删除 时 ， 新 版 本 的 文档 就 会 被 复制 到 集 
群 中 的 其 他 节点 上 。Elasticsearch 即 是 同步 的 又 是 异步 的 ， 也 就 是 说 复制 的 请 求 被 平行 发 送 
出 去 ， 然 后 可 能 会 混乱 地 到 达 目 的 地 。 这 就 需要 一 种 方法 能 够 保证 新 的 数据 不 会 被 日 数据 所 


Ric ° 


我 们 在 上 文 提 到 每 当 有 索引 、 put 和 me 的 操作 时 ， 无 论文 档 有 没有 变化 ， 它 
的 _version 都 会 增加 。Elasticsearch 使 用 _version 来 确保 所 有 的 改变 操作 都 被 正确 排序 。 如 
果 一 个 昌 的 版 本 出 现在 新 版 本 之 后 ， 它 就 会 被 忽略 掉 。 


我 们 可 以 利用 _version 的 优点 来 确保 我 们 程序 修改 的 数据 冲突 不 会 造成 数据 丢失 。 我 们 可 以 
按照 我 们 的 想法 来 指定 version 的 数字 。 如 果 数 字 错 误 ， 请 求 就 是 失败 。 


我 们 来 创建 一 个 新 的 博文 : 


PUT /website/blog/i/_create 

{ 
Meals My Apatictsie: IOo EAEN 
Meee St Eny Ng EMTS ou 


} 


反馈 告诉 我 们 这 是 一 个 新 建 的 文档 ， 它 的 _version 是 1 。 假 设 我 们 要 编辑 它 ， 把 这 个 数据 加 
载 到 网 页 表单 中 ， 修 改 完 毕 然 后 保存 新 版 本 。 


首先 我 们 先 要 得 到 文档 : 


GET /website/blog/1 


返回 结果 显示 _version 为 1 


{ 
TeX "website", 
eo "blog", 
STE al 
So 
"found" : true, 
" source" : { 
“title”; “My farst blog entry”, 
Wieey gee JUSt Ery ing ENES OUTA 
} 
} 


现在 ， 我 们 试 着 重新 索引 文档 以 保存 变化 ， 我 们 这 样 指 定 了 version 的 数字 : 


PUT /website/blog/i?version=1 <i> 


{ 
“titlet: GMY farst blogrentry. 


EeXt :Startang Eo get thes hang) of CNIS ec 


1. 我 们 只 希望 当 索 引 中 文档 的 version 是 1 时 ， 更 新 才 生 效 。 


请 求 成 功 相 应 ， 返 回 内 容 告 诉 我 们 versin 已 经 变 成 了 2 


{ 
"index": "website", 
" type": H oojo iy 
CETO Aaa 
"version": 2 
"created": false 

} 


然而 ， 当 我 们 再 执行 同样 的 索引 请 求 ， 并 依 昌 指定 version=1 时 ，Elasticsearch 就 会 返回 一 
个 409 Conflict 的 响应 码 ， 返 回 内 容 如 下 : 


{ 


"error" : "VersionConflictEngineException[[website][2] [blog][1]: 
version conflict, current [2], provided [1]]", 
"status" : 409 


这 里 面 指 出 了 文档 当前 的 version 数字 是 2 ， 而 我 们 要 求 的 数字 是 ° 


我 们 需要 做 什么 取决 于 我 们 程序 的 需求 。 比 如 我 们 可 以 告知 用 户 已 经 有 其 它 人 修改 了 这 个 文 
档 ， 你 应 该 再 保存 之 前 看 一 下 变化 。 而 对 于 上 文 提 到 的 库存 量 问题 ， 我 们 可 能 需要 重新 读 取 
一 下 最 新 的 文档 ， 然 后 显示 新 的 数据 。 


所 有 的 有 关于 更 新 或 者 删除 文档 的 API 都 支持 version 这 个 参数 ， 有 了 它 你 就 通过 修改 你 的 程 
序 来 使 用 乐观 并 发 控制 。 


使 用 外 部 系统 的 版 本 


还 有 一 种 常见 的 情况 就 是 我 们 还 是 使 用 其 他 的 数据 库 来 存储 数据 ， 而 Elasticsearch 只 是 帮 有 我 
们 检索 数据 。 这 也 就 意味 着 主 数据 库 只 要 发 生 的 变更 ， 就 需要 将 其 找 贝 到 Elasticsearch 中 。 
如 果 多 个 进程 同时 发 生 ， 就 会 产生 上 文 提 到 的 那些 并 发 问题 。 


如 果 你 的 数据 库 已 经 存在 了 版 本 号 码 ， 或 者 也 可 以 代表 版 本 的 HAR 。 这 是 你 就 可 以 在 
Elasticsearch 的 查询 字符 串 后 面 添 加 version_type=external 来 使 用 这 些 号 码 。 版 本 号 码 必须 
要 是 大 于 零 小 于 9.2e+18 (Java 中 long 的 最 大 正 值 ) 的 整数 。 


Elasticsearch 在 处 理 外 部 版 本 号 时 会 与 对 内 部 版 本 号 的 处 理 有 些 不 同 。 它 不 再 是 检 

查 _version 是 否 与 请 求 中 指定 的 数值 相 同 ,而 是 检查 当前 的 _version 是 否 比 指定 的 数值 小 9 
如 果 请 求 成 功 ， 那 么 外 部 的 版 本 号 就 会 被 存储 到 文档 中 的 _version 中 。 

外 部 版 本 号 不 仅 可 以 在 索引 和 删除 请 求 时 使 用 ， 还 可 以 在 创建 时 使 用 。 

例如 ， 创 建 一 篇 使 用 外 部 版 本 号 为 5 的 博文 ， 我 们 可 以 这 样 操作 : 


PUT /website/blog/2?version=5&version_type=external 


{ 
"title": "My first external blog entry", 


"text: "Starting to get the hang of this..." 
} 


在 返回 结果 中 ， 我 们 可 以 发 现 version = 5 : 


"_index": "website", 
"type" 0 "blog", 
erde ; ae 


“aversion: t5, 
"created": true 


现在 我 们 更 新 这 个 文档 ， 并 指定 version A 10 


PUT /website/blog/2?version=10&version_type=external 


{ 
"title": “My first external blog entry", 
"text": "This is a piece of cake..." 


请 求 被 成 功 执 行 并 且 version 也 变 成 了 10 


{ 
wlaindex": "website", 
" type": Oo 
SETANE T20 
"version": 10, 
"created": false 

} 


站 


o 


如 果 你 再 次 执行 这 个 命令 ， 你 会 得 到 之 前 的 错误 提示 信息 ， 因 为 你 所 指定 的 版 本 号 并 没有 大 
于 当前 Elasticsearch 中 的 版 本 号 


更 新 文档 中 的 一 部 分 


在 《更 新 》 一 章 中 ， 我 们 讲 到 了 要 是 想 更 新 一 个 文档 ， 那 么 就 需要 去 取 回 数据 ， 更 改 数据 然 
后 将 整个 文档 进行 重新 索引 。 当 然 ， 你 还 可 以 通过 使 用 更 新 API 来 做 部 分 更 新 ， 比 如 增加 一 
个 计数 器 。 

正如 我 们 提 到 的 ， 文 档 不 能 被 修改 ， 它 们 只 能 被 蔡 换 看 。 更 新 AP| 也 必须 遵循 这 一 法 则 。 从 
表面 看 来 ， 和 貌似 是 文档 被 替换 了 。 对 内 而 言 ， 它 必须 按照 找 回 -修改 -索引 的 流程 来 进行 操作 与 
管理 。 不 同 之 处 在 于 这 个 流程 是 在 一 个 片 (shard) 中 完成 的 ， 因 此 可 以 节省 多 个 请 求 所 带 来 的 
网 络 开 销 。 除 了 节省 了 步骤 ， 同 时 我 们 也 能 减少 多 个 进程 造成 冲突 的 可 能 性 。 

使 用 更 新 请 求 最 简单 的 一 种 用 途 就 是 添加 新 数据 。 新 的 数据 会 被 合并 到 现 有 数据 中 ， 而 如 果 
存在 相同 的 字段 ， 就 会 被 新 的 数据 所 替换 。 例 如 我 们 可 以 为 我 们 的 博客 添加 tags 和 views 字 


段 : 


POST /website/blog/i/_update 


Eagsw ii testeung le 
"views": 0 


如 果 请 求 成 功 ， 我 们 就 会 收 到 一 个 类 似 于 索引 时 返回 的 内 容 : 


{ 
"index" : "website", 
Weslo} g spss 
EVDe i: 四 加 下 QQ 
"_version" : 3 

} 


再 次 取 回 数据 ， 你 可 以 在 _source 中 看 到 更 新 的 结果 : 


"_index": "website", 
"type": "blog", 
ist Claas wale 
"version": 3, 
"Found": true, 


SESOURCC uta 
"title": “My first blog entry", 
"textar "Starting to get the hang of this...", 
Wicelofs a |E Meee ||, ceils 
"views": 0 <i> 


1. 新 的 数据 已 经 添加 到 了 字段 source 中 。 


使 用 脚本 进行 更 新 


我 们 将 会 在 《脚本 》 一 章 中 学 习 更 详细 的 内 容 ， 我 们 现在 只 需要 了 解 一 些 在 Elasticsearch 中 
使 用 API 无 法 直接 完成 的 自 定义 行为 。 黑 认 的 脚本 语言 叫做 MVEL， 但 是 Elasticsearch 也 支持 
JavaScript, Groovy 以 及 Python ° 


MVEL 是 一 个 简单 高 效 的 JAVA 基础 动态 脚本 语言 ， 它 的 语法 类 似 于 Javascript 。 你 可 以 
在 Elasticsearch scripting docs 以 及 MVEL website 了 解 更 多 关于 MVEL 的 信息 。 


脚本 语言 可 以 在 更 新 API 中 被 用 来 修改 source 中 的 内 容 ， 而 它 在 脚本 中 被 称 
为 ctx._source 。 例 如 ， 我 们 可 以 使 用 脚本 来 增加 博文 中 views 的 数字 : 


POST /website/blog/i/_update 
{ 


"script" : "ctx. source.views+t=1" 


} 


我 们 同样 可 以 使 用 脚本 在 tags 数组 中 添加 新 的 tag。 在 这 个 例子 中 ， 我 们 把 新 的 tag 声 明 为 一 
个 变量 ， 而 不 是 将 他 写 死 在 脚本 中 。 这 样 Elasticsearch 就 可 以 重新 使 用 这 个 脚本 进行 tag 的 添 
加 ， 而 不 用 再 次 重新 编写 脚本 了 : 


POST /website/blog/i/_update 


{ 
"script" : "ctx._source.tags+=new_tag", 
"params" : { 
newatag search” 
} 
} 


获取 文档 ， 后 两 项 发 生 了 变化 : 


{ 
" index": "website", 
“typet: sl ol oxo Wp 
oC val 
"version: 5; 
"found": true, 
C=SOURCC ail 
"title": "My first blog entry", 
"text: "Starting to get the hang of this...", 
"tags": ["testing”, “search"], <1> 
"views": 1 <2> 
} 
} 


. tags 数组 中 出 现 了 search ° 
2. views 字段 增加 了 。 


我 们 甚至 可 以 使 用 ctx.op 来 根据 内 容 选择 是 否 删 除 一 个 文档 : 


POST /website/blog/i/_update 


{ 
"Script" : "ctx.op = ctx._source.views == count ? delete : 'none'", 
params : { 
Scounten L 
} 
} 


更 新 一 篇 可 能 不 存在 的 文档 


想象 一 下 ， 我 们 可 能 需要 在 Elasticsearch 中 存储 一 个 页 面 计 数 器 。 每 次 用 户 访 问 这 个 页 面 ， 
我 们 就 增加 一 下 当前 页 面 的 计数 器 。 但 是 如 果 这 是 个 新 的 页 面 ， 我 们 不 能 确保 这 个 计数 器 已 
经 存在 。 如 果 我 们 试 着 去 更 新 一 个 不 存在 的 文档 ， 更 新 操作 就 会 失败 。 


为 了 防止 上 述 情 况 的 发 生 ， 我 们 可 以 使 用 upsert 参数 来 设 定 文 档 不 存在 时 ， 它 应 该 被 创建 : 


POST /website/pageviews/i/_update 


{ 
“SCPIDE .CLEX SOUnCERVICWS k= Mi, 
Junsenmt i 
"views": 1 
} 
} 


首次 运行 这 个 请 求 时 ， upsert 的 内 容 会 被 索引 成 新 的 文档 ， 它 将 views 字段 初始 化 为 1 。 
当 之 后 再 请 求 时 ， 文 档 已 经 存在 ， 所 以 脚本 更 新 就 会 被 执行 ， views 计数 器 就 会 增加 。 


更 新 和 冲突 


在 本 节 的 开篇 我 们 提 到 了 当 取 回 与 重新 索引 两 个 步骤 间 的 时 间 越 少 ， 发 生 改 变 冲 突 的 可 能 
就 越 小 。 但 它 并 不 能 被 完全 消除 ， 在 更 新 的 过 程 中 还 可 能 存在 另 一 个 进程 进 ee 
能 性 。 


为 了 避免 丢失 数据 ， 更 新 API 会 在 获取 步骤 中 获取 当前 文档 中 的 version ， 然 后 将 其 传递 给 
重新 索引 步骤 中 的 索引 请 求 。 如 果 其 他 的 进程 在 这 两 部 之 问 修改 了 这 个 文档 ， 那 
A version 就 会 不 同 ， 这样 更 新 就 会 失败 。 


对 于 很 多 的 局 部 更 新 来 说 ， 文档 有 没有 发 生变 化 实际 上 是 不 重要 的 。 例 如 ， 两 个 进程 都 要 增 
加 页 面 浏 览 的 计数 器 ， 谁 先 谁 后 其 实 并 不 重要 一 一 发 生 冲 突 时 只 需要 重新 来 过 即 可 。 


你 可 以 通过 设 定 retry_on_conflict 参数 来 设置 自动 完成 这 项 请 求 的 次 数 ， 它 的 默认 值 是 @ ° 


POST /website/pageviews/1/_update?retry_on_conflict=5 <i> 


{ 
"Script" : "ctx._source.views+=1", 
UPSe s af 
"views": 0 
} 
} 


1， 失 败 前 重新 党 试 5 次 


这 个 参数 非常 适用 于 类 似 于 增加 计数 器 这 ee 但 是 还 有 些 情况 的 顺序 就 是 很 
重要 的 。 例 如 上 一 节 提 到 的 情况 ， 你 可 以 参考 乐观 并 发 控制 以 及 悲观 并 发 控制 来 设 定 文档 的 
版 本 号 。 


获取 多 个 文档 


尽管 Elasticsearch 已 经 很 快 了 ， 但 是 它 依旧 可 以 更 快 。 你 可 以 将 多 个 请 求 合并 到 一 个 请 求 中 
以 节省 网 络 开 销 。 如 果 你 需要 从 Elasticsearch 中 获取 多 个 文档 ， 你 可 以 使 用 multi-get 或 者 
mget API| 来 取代 一 篇 又 一 篇 文档 的 获取 。 


mget API 需 要 一 个 docs 数组 ， 每 一 个 元 素 包 含 你 想 要 的 文档 的 _index ，_type AR _ia ° 
你 也 可 以 指定 _source 参数 来 设 定 你 所 需要 的 字段 : 


GET /_mget 
{ 
docs i] 
{ 
"_index" : "website", 
VESEY PCW DOG. Y, 
nell) dH 2 
}, 
"index" : "website", 
Paty pel pageviews 
nie | aba 
"source: “yiews™ 
} 
] 
} 


返回 值 包 含 了 一 个 docs 数组 ， 这 个 数组 以 请 求 中 指定 的 顺序 每 个 文档 包含 一 个 响应 。 每 一 个 
响应 都 和 独立 的 get 请 求 返回 的 响应 相同 : 


OCS 
{ 
"index" : "website", 
Ol Deis 
EVDe “biog! a, 
“Found! k: true, 
" source" : { 
itext : "this as a piece of cake... .", 
"title" : "My first external blog entry" 
} 
“version : 10 
}, 
{ 
"_index" : "website", 
METAN: R 
WEG E Oe iB "pageviews", 
“founds: treue 
HEVES TON pneu, 
SOUrCe f 
"views" : 2 
} 
} 
] 


如 果 你 所 需要 的 文档 都 在 同一 个 _index 或 者 同一 个 _type 中 ， 你 就 可 以 在 URL 中 指定 一 个 默 
认 的 /_index 或 是 /_index/_type 。 


你 也 可 以 在 单独 的 请 求 中 重 写 这 个 参数 : 


GET /website/blog/_mget 


{ 
EdOcCs 
E M OA 2 
{typer pageviews = Tdi: a} 
] 
} 


事实 上 ， 如 果 所 有 的 文档 拥有 相同 的 _index 以 及 _type ， 直 接 在 请 求 中 添加 ids 的 数组 即 
可 : 


GET /website/blog/_mget 


{ 
"ids" : [ naw wga ] 


请 注意 ， 我 们 所 请 求 的 第 二 篇 文档 不 存在 ， 这 是 就 会 返回 如 下 内 容 : 


{ 


Toes x 
{ 
"index" : "website", 
CYDe & “billogie, 
W alo? 8 ae 
"version" : 10, 
lo role true, 
Wesounce! =) 4 
"title": "My first external blog entry", 
exits: WINDSeaSmae prece or caken 
} 
}, 
{ 
"indexi: "website", 
"typen: 四 biOgie 
EC ele, 
whounde ee false <1> 
} 
] 


1. 文档 没有 被 找到 。 
当 第 二 篇 文档 没有 被 找到 的 时 候 也 不 会 影响 到 其 它 文档 的 获取 结果 。 每 一 个 文档 都 会 被 独立 
注意 : 上 方 请 求 的 HTTP 状 态 码 依 昌 是 200 ， 尽 管 有 个 文档 没有 找到 。 事 实 上 ， 即 使 所 有 的 文 


档 都 没有 被 找到 ， 响 应 码 也 依旧 是 200 。 这 是 因为 met 这 个 请 求 本 身 已 经 成 功 完 成 。 要 确 
定 独立 的 文档 是 否 被 成 功 找 到 ， 你 需要 检查 found 标识 。 


批量 更 高 效 


与 mget 能 同时 允许 帮助 我 们 获取 多 个 文档 相同 ， bulk API 可 以 帮助 我 们 同时 完成 执行 多 个 
请 求 ， 比 如 : create ， index, update 以 及 delete 。 当 你 在 处 理 类 似 于 log 等 海量 数据 的 时 
候 ， 你 就 可 以 一 下 处 理 成 百 上 千 的 请 求 ， 这 个 操作 将 会 极 大 提高 效率 。 


bulk 的 请 求 主 体 的 格式 稍微 有 些 不 同 : 


action: { metadata }}\n 
request body JAn 
action: { metadata }}\n 
request body JAn 


AAAS 


这 种 格式 就 类 似 于 一 个 用 "\n" 字符 来 连接 的 单行 json 一 样 。 下 面 是 两 点 注意 事项 : 


© 每 一 行 都 结尾 处 都 必须 有 换行 字符 "\n" ， 最 后 一 行 也 要 有 。 这 些 标记 可 以 有 效 地 分 隔 每 
行 。 
。 这 些 行 里 不 能 包含 非 转 义 字符 ， 以 免 干 扰 数 据 的 分 析 一 一 这 也 意味 着 JSON 不 能 是 


pretty-printed 样 式 。 


TIP 


在 《bulk 格 式 》 一 章 中 ， 我 们 将 解释 为 何 buik API 要 使 用 这 种 格式 。 


action/metadata 行 指 定 了 将 要 在 哪个 文档 中 执行 什么 操作 。 


其 中 action 必 须 是 index , create , update 或 者 delete ° metadata 需要 指明 需要 被 操作 文 
档 的 _index ，_type 以 及 id ， 例 如 删除 命令 就 可 以 这 样 填写 


{ "delete": { "_index": "website", "_type": "blog", "_id": "123" }} 


在 你 进行 index 以 及 create 操作 时 ，request body 行 必 须要 包含 文档 的 _source 数据 一 一 也 
就 是 文档 的 所 有 内 容 。 


同样 ， 在 执行 update API: doc, upsert , script 的 时 候 ， 也 需要 包含 相关 数据 。 而 在 删除 
的 时 候 就 不 需要 request body 行 。 


Bulk 


(elieatee Sundex :9 websiter EVDeaniinoiOogA TU 和 3 小 
{ "title": "My first blog post" } 


如 果 没 有 指定 id ， 那 么 系统 就 会 自动 生成 一 个 ID : 


(ndexn nduexeWVebsnce > tye: blog yi 
Tetit len "My second blog post" } 


完成 以 上 所 有 请 求 的 bulk 如 下 : 


POST /_bulk 

{delete e sndexWwensce EVDe mo 23> 

{ee Cheavens Mindex websites, eo typet aplogit Seidi: A1232 

TETE Le "My first blog post" } 

{ "index": { "_index": “website", " type": "blog" }} 

TEENE TOA "My second blog post" } 

{updaten linex Websitem a ete: DLO .Td Walks Ere Eny ON ECON LETCE 
BE 

{doc tuele My updated Diog post] <2> 


1. 注意 delete 操作 是 如 何 处 理 request body 的 ,你 可 以 在 它 之 后 直接 执行 新 的 操作 。 
2. 请 记 住 最 后 有 换行 符 


Elasticsearch 会 返回 含有 items 的 列表 、 它 的 顺序 和 我 们 请 求 的 顺序 是 相同 的 : 


人 OK 4 
"errors": false, <1> 
"items": [ 
{ “delete: { 
"index": "website", 
" type": "blog", 
U iag Taku 
"version": 2, 
"status": 200, 
"found": true 
HH, 
{ "create": { 
"index": "website", 
"type": "blog", 
Taig Teas. 
"_version": 3, 
"status": 201 
HH, 
{oreate { 
"_index": "website", 
" type": "blog", 
cedi: "EiwfApScQiiy7TIKFXRCTw", 
"version": 1, 
"status": 201 
}}, 
{ "update": { 
"_index": "website", 
"_type": "blog", 
ls 212307 
"_version": 4, 
"status": 200 
}} 


}} 


1， 所 有 的 请 求 都 被 成 功 执行 。 
每 一 个 子 请 求 都 会 被 单独 执行 ， 所 以 一 旦 有 一 个 子 请 求 失败 了 ， 并 不 会 影响 到 其 他 请 求 的 成 
功 执行 。 如 果 一 旦 出 现 失败 的 请 求 ， error 就 会 变 为 true ， 详 细 的 错误 信息 也 会 出 现在 返回 
内 容 的 下 方 : 


POST /_bulk 

{ "create": { "_index": “website”, "_type": “blog", "_id": "123" }} 
Te "Cannot create - it already exists" } 

{ “iandex": { "_index™: “website™, "“_type": “blog", "_id": "123" }} 
(Eesti "But we can update it" } 


请 求 中 的 create 操作 失败 ， 因 为 123 已 经 存在 ， 但 是 之 后 针对 文档 123 的 index 操作 依旧 
被 成 功 执 行 


{ 
EQOKk :3 
"errors": true, <1> 
"items": [ 
{ "create": { 
"index": "website", 
"_type": "blog", 
Used: 12307 
"status": 409, <2> 
"error": "DocumentAlreadyExistsException <3> 
[[website][4] [blog][123]: 
document already exists]" 
}}, 
‘ndex at 
"_index": "website", 
" type": "blog", 
Dic Mee, 
"version": 5, 
"status": 200 <4> 
}} 
] 
} 
1. 至 少 有 一 个 请 求 错误 发 生 。 
2. 这 条 请 求 的 状态 码 为 469 CONFLICT ° 
3. 错误 信息 解释 了 导致 错误 的 原因 。 
4. 第 二 条 请 求 的 状态 码 为 290 0K ° 


这 也 更 好 地 解释 了 bulk 请 求 是 独立 的 ， 每 一 条 的 失败 与 否 都 不 会 影响 到 其 他 的 请 求 。 


能 省 就 省 
或 许 你 在 批量 导入 大 量 的 数据 到 相同 的 index 以 及 type 中 。 每 次 都 去 指定 每 个 文档 的 
metadata 是 完全 没有 必要 的 。 在 mget APIP > bulik 请 求 可 以 在 URL 中 声明 /_ index 或 


者 /_index/_type 


POST /website/_bulk 
{ "index" : { "_type" > Vlogs }} 
T eventi: User logged inay 


你 依旧 可 以 在 metadata 行 中 使 用 _index 以 及 _type 来 重 写 数 据 ， 未 声明 的 将 会 使 用 URL 中 的 
置 作为 默认 值 : 


POST /website/log/_bulk 

{ "index": {}} 

(evemte User logged Ina y 

(ridex i EVDe n aD Logun ao 

{titlen Overriding the default eype 


最 大 有 多 大 ? 


整个 数据 将 会 被 处 理 它 的 节点 载 入 内 存 中 ， 所 以 如 果 请 求 量 很 大 的 话 ， 留 给 其 他 请 求 的 内 存 
空间 将 会 很 少 。 buk 应 该 有 一 个 最 佳 的 限度 。 超 过 这 个 限制 后 ， 性 能 不 但 不 会 提升 反而 可 能 
会 造成 宕 机 。 


最 佳 的 容量 并 不 是 一 个 确定 的 数值 ， 它 取决 于 你 的 硬件 ， 你 的 文档 大 小 以 及 复杂 性 ， 你 的 索 
引 以 及 搜索 的 负载 。 幸 运 的 是 ， 这 个 平衡 点 很 容易 确定 : 


试 着 去 批量 索引 越 来 越 多 的 文档 。 当 性 能 开始 下 降 的 时 候 ， 就 说 明 你 的 数据 量 太 大 了 。 一 般 

比较 好 初始 数量 级 是 1000 到 5000 个 文档 ， 或 者 你 的 文档 很 大 ， 你 就 可 以 试 着 减 小 队列 。 有 的 
时 候 看 看 批量 请 求 的 物理 大 小 是 很 有 帮助 的 。1000 个 1KB 的 文档 和 1000 个 1MB 的 文档 的 差距 
将 会 是 天 差 地 别 的 。 上 比较 好 的 初始 批量 容量 是 5-15MB © 


总 结 
现在 你 应 该 知道 如 何 作为 分 布 式 文档 存储 来 使 用 Elasticsearch。 你 可 以 对 文档 进行 存储 ， 更 

新 ， 获 取 ， 删 除 操作 ， 而 且 你 还 知道 该 如 何 安全 的 执行 这 些 操作 。 这 已 经 非常 有 用 处 了 ， 印 

使 我 们 现在 仍然 没有 尝试 更 激动 人 心 的 方面 -- 在 文档 中 进行 查询 操作 。 不 过 我 们 先 探讨 下 分 
布 式 环境 中 Elasticsearch 安 全 管理 你 的 文档 所 使 用 的 内 部 过 程 。 


分 布 式 文 档 存储 
本 章 将 会 在 主要 章节 翻译 结束 后 再 继续 翻译 


In the last chapter, we looked at all the ways to put data into your index and then retrieve it. 
But we glossed over many technical details surrounding how the data is distributed and 
fetched from the cluster. This separation is done on purpose -- you don't really need to know 
how data is distributed to work with Elasticsearch. It just works. 


In this chapter, we are going to dive into those internal, technical details to help you 
understand how your data is stored in a distributed system. 


内 oy He AE 
A) & 3 wv 


V 


The information presented below is for your interest. You are not required to understand and 
remember all the detail in order to use Elasticsearch. The options that are discussed are for 
advanced users only. 


Read the section to gain a taste for how things work, and to know where the information is in 
case you need to refer to it in the future, but don't be overwhelmed by the detail. 


将 文档 路 由 到 从 库 中 


当 你 索引 一 个 文档 ， 它 被 保存 在 单个 的 主 分 片上 ，Elasticsearch 如 何 知 道 文档 属于 哪个 分 片 
呢 ?” 当 我 们 创建 一 个 新 文档 ， 它 如 何 知 道 应 该 存储 在 分 片 1 还 是 分 片 2 上 呢 ? 


这 个 过 程 不 能 是 随机 的 ， 因 为 我 们 将 来 需要 取 回 该 文档 。 事 实 上 ， 它 是 由 一 个 非常 简单 的 公 
式 来 决定 的 : 


分 片 = hash(routing) % 主 分 片 数量 


routing 值 可 以 是 任何 的 字符 串 ， 默 认 是 文档 的 id ， 但 也 可 以 设置 成 一 个 自 定义 的 值 。 
routing 字符 串 被 传递 到 一 个 哈 希 函数 以 生成 一 个 数字 ， 然 后 除 以 索引 的 主 分 片 的 数量 得 到 
余数 remainder. 余数 将 总 是 在 9 到 主 分 片 数量 - 1 ZA, 它 告 诉 了 我 们 用 以 存放 一 个 特定 
文档 的 分 片 编号 。 


这 解释 了 为 什么 主 分 片 的 数量 只 能 在 索引 创建 时 设置 、 而 且 不 能 修改 。 如 果 主 分 片 的 数量 一 
旦 在 日 后 进行 了 修改 ， 所 有 之 前 的 路 由 值 都 会 无 效 ， 文 档 再 也 无 法 被 找到 。 


所 有 文档 APIs ( get ，index ，delete , bulk ，update 和 mget ) 都 可 以 接受 routing 参 
数 ， 用 以 自 定 义 文档 -到 -分 片 的 映射 。 自 定义 的 路 由 将 用 于 确保 所 有 的 文档 -- 例如 属于 同一 
用 户 的 所 有 文档 -- 保存 在 相同 的 分 片上 。 我 们 将 在 ”<< 扩 展 >> 中 详细 讨论 你 为 什么 希望 这 人 么 
做 。 


主 从 库 之 间 是 如 何 通信 的 


For explanation purposes, let's imagine that we have a cluster consisting of 3 nodes. It 
contains one index called blogs which has two primary shards. Each primary shard has 
two replicas. Copies of the same shard are never allocated to the same node, so our cluster 
looks something like <>. 


[[img-distrib]] .A cluster with three nodes and one index image::images/04-01_index.png["A 
cluster with three nodes and one index"] 


We can send our requests to any node in the cluster. Every node is fully capable of serving 
any request. Every node knows the location of every document in the cluster and so can 
forward requests directly to the required node. In the examples below, we will send all of our 
requests to Node 1 , which we will refer to as the requesting node. 


TIP: When sending requests, it is good practice to round-robin through all the nodes in the 
cluster, in order to spread the load. 


创建 、 索 引 、 删 除 文档 


Create, index and delete requests are write operations, which must be successfully 
completed on the primary shard before they can be copied to any associated replica shards. 


[[img-distrib-write]] .Creating, indexing or deleting a single document image::images/04- 
02_write.png["Creating, indexing or deleting a single document") 


Below we list the sequence of steps necessary to successfully create, index or delete a 
document on both the primary and any replica shards, as depicted in <>: 


1. The client sends a create, index or delete request to Node 1 . 


2. The node uses the document's _id to determine that the document belongs to shard 
o . It forwards the request to Node 3 , where the primary copy of shard o is currently 
allocated. 


3. Node 3 executes the request on the primary shard. If it is successful, it forwards the 
request in parallel to the replica shards on Node 1 and Node 2 . Once all of the replica 
shards report Success, Node 3 reports success to the requesting node, which reports 
success to the client. 


By the time the client receives a successful response, the document change has been 
executed on the primary shard and on all replica shards. Your change is safe. 


There are a number of optional request parameters which allow you to influence this 
process, possibly increasing performance at the cost of data security. These options are 
seldom used because Elasticsearch is already fast, but they are explained here for the sake 
of completeness. 


replication :: 


afa 


The default value for replication is sync . This causes the primary shard to wait for 
successful responses from the replica shards before returning. 


If you set replication to async , then it will return success to the client as soon as the 
request has been executed on the primary shard. It will still forward the request to the 
replicas, but you will not know if the replicas succeeded or not. 


It is advisable to use the default sync replication as it is possible to overload Elasticsearch 
by sending too many requests without waiting for their 


completion. 


consistency :: 


中 


By default, the primary shard requires a quorum or majority of shard copies (where a shard 
copy can be a primary or a replica shard) to be available before even attempting a write 
operation. This is to prevent writing data to the “wrong side" of a network partition. A 
quorum is defined as: 


int( (primary + number_of_replicas) / 2 )+ 1 


The allowed values for consistency are one (just the primary shard), all (the primary 
and all replicas) or the default quorum or majority of shard copies. 


Note that the number_of_replicas is the number of replicas specified in the index settings, 
not the number of replicas that are currently active. If you have specified that an index 
should have 3 replicas then a quorum would be: 


int( (primary + 3 replicas) / 2 )+1= 3 


But if you only start 2 nodes, then there will be insufficient active shard copies to satisfy the 
quorum and you will be unable to index or delete any documents. 


timeout :: 


What happens if insufficient shard copies are available? Elasticsearch waits, in the hope that 
more shards will appear. By default it will wait up to one minute. If you need to, you can use 
the timeout parameter to make it abort sooner: 100 is 100 milliseconds, 30s is 30 
seconds. 


[NOTE] 


Anew index has 1 replica by default, which means that two active shard copies should be 
required in order to satisfy the need fora quorum . However, these default settings would 
prevent us from doing anything useful with a single-node cluster. To avoid this problem, the 
requirement for 


a quorum is only enforced when 
number_of_replicas is greater than 1. 


获取 一 个 文档 

Adocument can be retrieved from a primary shard or from any of its replicas. 
[[img-distrib-read]] .Retrieving a single document image::images/04-03_get.png["Retrieving 
a single document" ] 


Below we list the sequence of steps to retrieve a document from either a primary or replica 


shard, as depicted in <>: 
1. The client sends a get request to Node 1. 


2. The node uses the document's _id to determine that the document belongs to shard 
o . Copies of shard o exist on all three nodes. On this occasion, it forwards the 


request to Node 2. 


3. Node 2 returns the document to Node 1 which returns the document to the client. 


For read requests, the requesting node will choose a different shard copy on every request 
in order to balance the load -- it round-robins through all shard copies. 


It is possible that a document has been indexed on the primary shard but has not yet been 
copied to the replica shards. In this case a replica might report that the document doesn't 
exist, while the primary would have returned the document successfully. 


更 新 文档 中 的 一 部 分 
The update API combines the read and write patterns explained above. 


[[img-distrib-update]] .Partial updates to a document image::images/04- 
04_update.png|["Partial updates to a document"] 


Below we list the sequence of steps used to perform a partial update on a document, as 
depicted in <>: 


1. The client sends an update request to Node 1 . 
2. It forwards the request to node 3 , where the primary shard is allocated. 


3. Node 3 retrieves the document from the primary shard, changes the JSON in the 
_source field, and tries to reindex the document on the primary shard. If the document 
has already been changed by another process, it retries step 3 up to 
retry_on_conflict times, before giving up. 


4. If Node 3 has managed to update the document successfully, it forwards the new 
version of the document in parallel to the replica shards on Node 1 and Node 2 tobe 
reindexed. Once all replica shards report Success, Node 3 reports success to the 
requesting node, which reports success to the client. 


The update API also accepts the routing , replication , consistency and timeout 
parameters that are explained in <>. 


When a primary shard forwards changes to its replica shards, it doesn't forward the update 
request. Instead it forwards the new version of the full document. Remember that these 
changes are forwarded to the replica shards asynchronously and there is no guarantee that 
they will arrive in the same order that they were sent. If Elasticsearch forwarded just the 
change, it is possible that changes would be applied in the wrong order, resulting in a corrupt 
document. 


多 文档 模式 


The patterns forthe mget and bulk APls are similar to those for individual documents. 
The difference is that the requesting node knows in which shard each document lives. It 
breaks up the multi-document request into a multi-document request per shard, and 
forwards these in parallel to each participating node. 


Once it receives answers from each node, it collates their responses into a single response, 
which it returns to the client. 


[[img-distrib-mget]] .Retrieving multiple documents with mget image::images/04- 
05_mget.png["Retrieving multiple documents with mget"] 


Below we list the sequence of steps necessary to retrieve multiple documents with a single 
mget request, as depicted in <>: 


1. The client sends an mget request to Node 1 . 


2. Node 1 builds a multi-get request per shard, and forwards these requests in parallel to 
the nodes hosting each required primary or replica shard. Once all replies have been 
received, Node 1 builds the response and returns it to the client. 


A routing parameter can be set for each document inthe docs array, andthe preference 
parameter can be set for the top-level mget request. 


[[img-distrib-bulk]] .Multiple document changes with bulk image::images/04- 
06_bulk.png["Multiple document changes with bulk"] 


Below we list the sequence of steps necessary to execute multiple create , index , 
delete and update requests within a single bulk request, as depicted in <>: 


1. The client sendsa bulk requestto Node 1 . 


2. Node 1 builds a bulk request per shard, and forwards these requests in parallel to the 
nodes hosting each involved primary shard. 


3. The primary shard executes each action serially, one after another. As each action 
succeeds, the primary forwards the new document (or deletion) to its replica shards in 
parallel, then moves on to the next action. Once all replica shards report success for all 
actions, the node reports success to the requesting node, which collates the responses 
and returns them to the client. 


The bulk APlalso accepts the replication and consistency parameters at the top-level 
for the whole bulk request, andthe routing parameter in the metadata for each request. 


批量 请 求 


88 


Why the funny format? 


When we learned about Bulk requests earlier in <>, you may have asked yourself: `why 
does the bulk API require the funny format with the newline characters, instead of just 


sending the requests wrapped in a JSON array, like the mget API?" 
To answer this, we need to explain a little background: 


Each document referenced in a bulk request may belong to a different primary shard, each 
of which may be allocated to any of the nodes in the cluster. This means that every action 
inside a bulk request needs to be forwarded to the correct shard on the correct node. 


If the individual requests were wrapped up in a JSON array, that would mean that we would 
need to: 


e parse the JSON into an array (including the document data, which can be very large) 
e look at each request to determine which shard it should go to 

e create an array of requests for each shard 

e serialize these arrays into the internal transport format 

e send the requests to each shard 


It would work, but would need a lot of RAM to hold copies of essentially the same data, and 
would create many more data structures that the JVM would have to spend time garbage 
collecting. 


Instead, Elasticsearch reaches up into the networking buffer, where the raw request has 
been received and reads the data directly. It uses the newline characters to identify and 
parse just the small action/metadata lines in order to decide which shard should handle each 
request. 


These raw requests are forwarded directly to the correct shard. There is no redundant 
copying of data, no wasted data structures. The entire request process is handled in the 
smallest amount of memory possible. 


搜索 -基本 工具 


到 目前 为 止 ， 我 们 已 经 学 习 了 Elasticsearch 的 分 布 式 NOSQL 文 档 存 储 ， 我 们 可 以 直接 把 
JSON 文 档 扔 到 Elasticsearch 中 ， 然 后 直接 通过 ID 来 进行 调 取 。 但 是 Elasticsearch 监 正 的 强大 
之 处 在 于 将 混乱 变 得 有 意义 一 一 将 大 数据 变 成 大 量 的 信息 。 


这 也 是 我 们 使 用 JSON 文 档 而 不 是 无 规则 数据 的 原因 。Elasticsearch 不 仅仅 只 是 存储 文档 ， 同 
时 它 还 索引 了 这 些 文档 以 便 搜 索 。 文 档 中 每 一 个 字段 都 被 索引 并 且 可 以 被 查询 。 不 仅 如 此 ， 

在 一 个 查询 中 ，Elasticsearch 可 以 使 用 所 有 索引 ， 并 且 以 惊人 的 速度 返回 结果 。 这 是 传统 数 
据 库 永远 也 不 能 企及 的 。 


这 个 搜索 可 以 是 : 


© RUT #8 、 性 别 、 加 入 日 期 等 结构 化 数据 ， 类 似 于 在 SQL 中 进行 查询 。 
@ 全 文 搜索 ， 查 找 整个 文档 中 匹配 关键 字 的 内 容 ， 并 根据 相关 性 
© 或 者 结合 两 者 。 


虽然 很 多 搜索 操作 是 安装 好 Elasticsearch 就 可 以 用 的 ， 但 是 想 发 挥 它 的 潜力 ， 你 需要 明白 以 
FAS: 


名 字 说 明 
映射 (Mapping) 每 个 字段 中 的 数据 如 何 被 解释 
统计 (Analysis) 可 搜索 的 全 文 是 如 何 被 处 理 的 
查询 (Query DSL) Elasticsearch 使 用 的 灵活 强 的 查询 语言 


上 述 的 每 一 个 内 容 都 是 一 个 大 的 主题 ， 我 们 将 会 在 之 后 的 《深入 搜索 》 中 详细 探讨 它们 。 本 
章 中 我 们 将 针对 先 去 介绍 它们 三 个 的 基本 概念 经 足够 能 帮助 你 理解 搜索 是 如 何 运 作 的 
了 o 











我 们 将 向 你 介绍 search API 的 简单 实用 方式 。 


测试 数据 
我 们 本 章 使 用 的 文档 可 以 在 下 面 的 git 中 找到 : https://gist.github.com/clintongormley/8579281 


你 可 以 下 载 然 后 导入 到 你 的 shell 中 以 方便 你 的 学 习 使 用 。 


空白 搜索 


搜索 API 最 常用 的 一 种 形式 就 是 空白 搜索 ， 也 就 是 不 加 任何 查询 条 件 的 ， 只 是 返回 集群 中 所 有 
文档 的 搜索 。 


GET /_search 


返回 内 容 如 下 (AAR) 


{ 
SMESAN 
Meo es Ya 14, 
ts 
{ 
"index": BU Siar, 
" type": "tweet", 
a alge pie Tbe 
SC ON a 
LESONG EA 
"date": "2014-09-17", 
"name": "John Smith", 
"tweet": "The Query DSL is really powerful and flexible", 
“user 1rd: 2 
} 
}, 
. 9 个 结 采 被 隐藏 ，.. 
], 
"max_score" : al! 
}, 
"took" : 4, 
eshardsy 3: i 
"Failed" : 0, 
"successful : 10, 
oa 10 
}, 
"timed_out" : false 
} 
hits 


返回 内 容 中 最 重要 的 内 容 就 是 hits ， 它 指明 了 匹配 查询 的 文档 的 总 数 ， hits 数组 里 则 会 包 
含 前 十 个 匹配 文档 一 一 也 就 是 搜索 结果 。 


hits 数组 中 的 每 一 条 结果 都 包含 了 文档 的 _index ，_type 以 及 _id i 息 ， 以 及 source F 
段 。 这 也 就 意味 着 你 可 以 直接 从 搜索 结果 中 获取 到 整个 文档 的 内 容 。 这 与 其 他 搜索 引擎 只 返 
回 给 你 文档 编号 ， 还 需要 自己 去 获取 文档 是 截然 不 同 的 。 


每 一 个 元 素 还 拥有 一 个 _score 字段 © 这 个 是 相 关 性 评分 4 这 个 数值 表示 当前 文档 与 查询 的 匹 
配 程度 。 通 常 来 说 ， 搜 索 结果 会 先 返回 最 匹配 的 文档 ， 也 就 是 说 它们 会 按照 score 由 高 至 低 
进行 排列 。 在 这 个 例子 中 ， 我 们 并 没有 声明 任何 查询 ， 因 此 _score 就 都 会 返回 1 


max_score 数值 会 显示 所 有 匹配 文档 中 的 _score 的 最 大 值 9 


took 


took 数值 告诉 我 们 执行 这 次 搜索 请 求 所 耗费 的 时 间 有 多 少 毫秒 。 


shards 


_shards 告诉 了 我 们 参与 查询 分 片 的 总 数 ， 以 及 有 多 少 successful 和 failed 。 通 常情 况 下 
我 们 是 不 会 得 到 失败 的 反馈 ， 但 是 有 的 时 候 它 会 发 生 。 如 果 我 们 的 服务 器 突然 出 现 了 重大 事 
故 ， 然 后 我 们 丢失 了 同一 个 分 片 中 主 从 两 个 版 本 的 数据 。 在 查询 请 求 中 ， 无 法 提供 可 用 的 备 
份 。 这 种 情况 下 ，Elasticsearch 就 会 返回 "failed 提 示 ， 但 是 它 还 会 继续 返回 剩 下 的 内 容 。 


timeout 


timed_out 数值 告诉 了 我 们 查询 是 否 超时 。 通 常 ， 搜 索 请 求 不 会 超时 。 如 果 相 比 完 整 的 结果 
你 更 需要 的 是 快速 的 响应 时 间 ， 这 是 你 可 以 指定 timeout 值 ， 例 如 10 ` "10ms" (10 毫秒) 
或 者 "1s" (1 秒 钟 ) 


GET /_search?timeout=10ms 


Elasticsearch 会 尽 可 能 地 返回 你 指定 时 间 内 它 所 查 到 的 内 容 。 


Timeout 并 不 是 终止 者 


这 里 应 该 强调 一 下 timeout 并 不 会 终止 查询 ， 它 只 是 会 在 你 指定 的 时 间 内 返回 当时 已 经 查询 
到 的 数据 ， 然 后 关闭 连接 。 在 后 人 台 ， 其 他 的 查询 可 能 会 依旧 继续 ， 尽 管 查 询 结 果 已 经 被 返回 
了 。 


使 用 超时 是 因为 你 要 保障 你 的 品质 ， 并 不 是 因为 你 需要 终止 你 的 查询 。 


空白 搜索 
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多 索引 ， 多 类 型 


尔 是 否 注 意 到 了 《 空 Re 一 章节 的 文档 中 包含 了 很 多 不 同 的 类 型 
它们 也 分 别 来 自 us > gb 这 两 个 不 同 的 索引 ? 


~ 


=~ 


user 与 tweet ° 





当 我 们 没有 特别 指定 一 个 索引 或 者 类 型 的 时 候 ， 我 们 将 会 搜索 整个 集群 中 的 所 有 文档 。 
Elasticsearch 会 把 搜索 请 求 转 发 给 集群 中 的 每 一 个 主 从 分 片 ， 然 后 按照 结果 的 相关 性 得 到 前 
十 名 ， 并 将 它们 返回 给 我 们 。 


然而 ， 往 往 我 们 只 需要 在 某 一 个 特定 的 索引 的 几 个 类 型 中 进行 搜索 。 我 们 可 以 通过 在 URL 中 
定义 它 来 实现 这 个 功能 


URL 说 明 
/_search 搜索 所 有 的 索引 和 类 型 
0 搜索 索引 gb 中 的 所 有 类 型 
/gb,us/_search 搜索 索引 gb 以 及 us 中 的 所 有 类 型 
/g*,u*/_search 搜索 所 有 以 g 或 u 开头 的 索引 中 的 所 有 类 型 
LOPAS SS 搜索 索引 gb 中 类 型 user 内 的 所 有 文档 
/gb, us/user, tweet/_search o 和 索引 us 中 类 型 user 以 及 类 型 tweet A 


/_all/user, tweet/_search 搜索 所 有 索引 中 类 型 为 user 以 及 tweet 内 的 所 有 文档 
当 你 在 一 个 索引 中 搜索 的 时 候 ，Elasticsearch 或 将 你 的 搜索 请 求 转发 给 相应 索引 中 的 所 有 主 


从 分 片 ， 然 后 收集 每 一 个 分 片 的 结果 。 在 多 个 索引 中 搜索 也 是 相同 的 流程 ， 只 不 过 是 增加 了 
一 些 参与 分 片 。 


重要 提示 


搜索 一 个 拥有 五 个 主 分 片 的 索引 与 搜索 五 个 都 只 拥有 一 个 主 分 片 是 完全 一 样 的 。 


在 后 面 ， 你 将 会 了 解 到 如 何 利 用 这 一 点 ， 来 根据 你 的 需要 灵活 打造 系统 。 


PN 
分 页 
在 《空白 搜索 》 一 节 中 ， 搜 索 结 果 告 诉 我 们 在 集群 中 共有 14 个 文档 匹配 我 们 的 (空白 ) 查 
询 。 但 是 在 hits 数组 中 只 有 10 个 文档 。 我 们 怎样 才能 看 到 其 他 的 呢 ? 


与 SQL 使 用 LIMIT 来 控制 单 “ 页 ”数量 类 似 ，Elasticsearch 使 用 的 是 from 以 及 size 两 个 参 
数 : 


参数 说 明 
Size 每 次 返回 多 少 个 结果 ， 上 默认 值 为 10 
from 忽略 最 初 的 几 条 结果 ， 默 认 值 为 o 


假设 每 页 显示 5 条 结果 ， 那 么 1 至 3 页 的 请 求 就 是 : 


GET /_search?size=5 
GET /_search?size=5&f rom=5 
GET /_search?size=5&from=10 


当心 不 要 一 次 请 求 过 多 或 者 页 码 过 大 的 结果 。 它 们 会 在 返回 前 排序 。 一 个 请 求 会 经 过 多 个 分 
片 。 每 个 分 片 都 会 生成 自己 的 排序 结果 。 然 后 再 进行 集中 整理 ， 以 确保 最 终结 果 的 正确 性 。 


分 布 式 系统 中 的 大 页 码 页 面 


为 了 说 明白 为 什么 页 码 过 大 的 请 求 会 产生 问题 ， 我 们 就 先 预想 一 下 我 们 在 搜索 一 个 拥有 5 个 主 
分 片 的 索引 。 当 我 们 请 求 第 一 页 搜索 的 时 候 ， 每 个 分 片 产生 自己 前 十 名 ， 然 后 将 它们 返回 给 
请 求 节点 ， 然 后 这 个 节点 会 将 50 条 结果 重新 排序 以 产生 最 终 的 前 十 名 。 


现在 想 想 一 下 我 们 想 获得 第 1,000 页 ， ee ream 010 条 结果 ， 与 之 前 同 理 ， 每 一 
个 分 片 都 会 先 产生 自己 的 前 10,010 名 ， 然 后 请 求 节点 统一 处 理 这 50,050 条 结果 ， 然 后 再 丢弃 
掉 其 中 的 50,040 条 ! 


现在 你 应 该 明白 了 ， 在 分 布 式 系统 中 ， 大 页 码 请 求 所 消耗 的 系统 资源 是 呈 指 数 式 增长 的 。 这 
也 是 为 什么 网 络 搜索 引擎 不 会 提供 超过 1,000 条 搜索 结果 的 原因 。 


TIP 


在 《 重 索 引 》 一 章 中 ， 我 们 将 详细 探讨 如 何 才能 高 效 地 获取 大 量 数据 。 


x 
aR 
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搜索 的 API 分 为 两 种 : 其 一 是 通过 参数 来 传递 查询 的 “精简 版 "查询 语句 (query string) ， 还 有 
一 种 是 通过 JSON 来 传达 丰富 的 查询 的 完整 版 请 求 体 (request body) ， 这 种 搜索 语言 被 称 为 
查询 [DSL ° 


查询 语句 在 行 命令 中 运行 点 对 点 查询 的 时 候 非常 实用 。 上 比如 我 想 要 查询 所 有 tweet 类 型 中 ， 
所 有 tweet FAA "elasticsearch" 的 文档 : 


GET /_all/tweet/_search?q=tweet:elasticsearch 


下 一 个 查询 是 想 要 寻找 name FAA "john" H tweet 字段 为 "mary" 的 文档， 实际 的 查询 就 


4 


Fe: 


t+name: john +tweet:mary 


但 是 经 过 百 分 号 编码 (percent encoding) 处 理 后 ， 会 让 它 看 起 来 稍 显 神秘 : 


GET /_search?q=%2Bname%3Aj ohn+%2Btweet%3Amary 


前 级 "4" 表示 必须 要 满足 我 们 的 查询 匹配 条 件 9 而 前 组 wou 则 表示 绝对 不 能 匹配 条 件 o 没 
有 + 或 者 - 的 表示 可 选 条 件 。 匹 配 的 越 多 ， 文 档 的 相关 性 就 越 大 。 

字段 all 

下 面 这 条 简单 的 搜索 将 会 返回 所 有 包含 "mary" 字符 的 文档 : 


GET /_search?q=mary 


在 之 前 的 例子 中 ， 我 们 搜索 tweet 或 者 name 中 的 文字 。 然 而 ， 搜 索 的 结果 显示 "mary" 在 三 
个 不 同 的 字段 中 : 


。 用 户 的 名 字 为 "Mary" 
e 6 个 "Mary" 发 送 的 推 文 
e 1 个 "@mary" 


那么 Elasticsearch 是 如 何 找 到 三 个 不 同 字 段 中 的 内 容 呢 ? 


当 我 们 在 索引 一 个 文档 的 时 候 ，Elasticsearch 会 将 所 有 字段 的 数值 都 汇总 到 一 个 大 的 字符 串 
中 ， 并 将 它 索 引 成 一 个 特殊 的 字段 all : 


"tweet": "However did I manage before Elasticsearch?", 
"date": "2014-09-14", 

"name": "Mary Jones", 

Huser rdin = aE 


就 好 像 我 们 已 经 添加 了 一 个 叫做 _all 的 字段 : 


"However did I manage before Elasticsearch? 2014-09-14 Mary Jones 1" 


除非 指定 了 字段 名 ， 不 然 查询 语句 就 会 搜索 字段 all 。 


TIP: 在 你 刚 开 始 创 建 程序 的 时 候 你 可 能 会 经 常 使 用 _all 这 个 字段 。 但 是 慢 慢 的 ， 你 可 能 就 会 
在 请 求 中 指定 字段 。 当 字段 all 已 经 没有 使 用 价值 的 时 候 ， 那 就 可 以 将 它 关 掉 。 之 后 的 《 字 
段 all》 一 节 中 将 会 有 介绍 


更 加 复杂 的 查询 


再 实现 一 个 查询 : 


e 字段 nme 包含 "mary" 或 "john" 
e date 大 于 2014-09-10 
e l all 字段 中 包含 "aggregations" 或 "geo" 


+name: (mary john) +date:>2014-09-10 +(aggregations geo) 


最 终 处 理 完 的 语句 可 读 性 可 能 很 差 : 

?9q=%2Bname%3A(mary+john )+%2Bdate%3A%3E2014-09-10+%2B(aggregations+geo) 
正如 你 所 看 到 的 ， 这 个 简明 查询 语句 是 出 奇 的 强大 。 在 查询 语句 语法 中 ， 有 关于 它 详细 的 介 
绍 。 借 助 它 我 们 就 可 以 在 开发 的 时 候 提 高 很 多 效率 。 


不 过 ， 你 也 会 发 现 简洁 带 来 的 易 读 性 差 和 难以 调试 ， 以 及 它 的 脆弱 : 当 其 中 出 现 - ，: ，/ 
或 者 " 时 ， 它 就 会 返回 错误 提示 。 


最 后 要 提 一 句 ， 任 何 用 户 都 可 以 通过 查询 语句 来 访问 脐 肿 的 查询 ， 或 许 会 得 到 一 些 私人 的 信 
息 ， 或 许 会 通过 大 量 的 运算 将 你 的 集群 压 震 ! 


TIP 
出 于 以 上 原因 ， 我 们 不 建议 你 将 查询 语句 直接 暴露 给 用 户 ， 除 非 是 你 信任 的 可 以 访问 数据 与 
集群 的 权限 用 户 。 


与 此 同时 ， 在 生产 环境 中 ， 我 们 经 常会 使 用 到 查询 语句 。 在 了 解 更 多 关于 搜索 的 知识 前 ， 我 
们 先 来 看 一 下 它 是 怎样 运作 的 。 


映射 与 统计 


当 我 们 在 进行 搜索 的 事情 ， 我 们 会 发 现 有 一 些 奇 怪 的 事情 。 比 如 有 一 些 内 容 似乎 是 被 打破 
了 : 在 我 们 的 索引 中 有 12 条 推 文 ， 中 有 一 个 包含 了 2014-09-15 这 个 日 期 ， 但 是 看 看 下 面 的 查 
询 结果 中 的 总 数量 : 


GET /_search?q=2014 # 12 results 
GET /_search?q=2014-09-15 # 12 results ! 
GET /_search?q=date:2014-09-15 #41 result 
GET /_search?q=date: 2014 #0 results ! 


为 什么 我 们 使 用 字段 all 搜索 全 年 就 会 返回 所 有 推 文 ， 而 使 用 字段 date 搜索 年 份 却 没有 结 
果 呢 ?为 什么 使 用 两 者 所 得 到 的 结果 是 不 同 的 ? 


推测 大 概 是 因为 我 们 的 数据 在 _all 和 date 在 索引 时 没有 被 相同 处 理 。 我 们 来 看 看 
Elasticsearch 是 如 何 处 理 我 们 的 文档 结构 的 。 我 们 可 以 对 gb 的 tweet 使 用 mapping 请 求 : 


GET /gb/_mapping/tweet 


我 们 得 到 : 
{ 
"gb": { 
"mappings": { 
"tweet": { 
tpropertiesi:i { 

dates 
by DCm Oa tel, 
"Format": "dateOptionalTime" 

}, 

"name": { 
"type": “string” 

}, 

“tweet: { 
Bey pele) oSiGraingu 

}, 

ausen rdus 
"type. “long! 

} 

} 
} 
} 
} 


Elasticsearch 会 根据 系统 自动 判断 字段 类 型 并 生成 一 个 映射 。 返 回 结果 告诉 我 们 date 字段 被 
识别 成 了 date 类 型 。 all 没有 出 现 是 因为 他 是 默认 字段 ， 但 是 我 们 知道 字段 all 实际 上 


是 string 类 型 的 。 


所 以 类 型 为 date 的 字段 和 类 型 为 string 的 字段 的 索引 方式 是 不 同 的 。 


So fields of type date and fields of type string are indexed differently, and can thus be 
searched differently. That's not entirely surprising. You might expect that each of the core 
data types -- strings, numbers, booleans and dates -- might be indexed slightly differently. 
And this is true: there are slight differences. 


But by far the biggest difference is actually between fields that represent exact values (which 
can include string fields) and fields that represent full text. This distinction is really 
important -- it's the thing that separates a search engine from all other databases. 


精确 值 与 全 文 


Data in Elasticsearch can be broadly divided into two types: exact values and full text. 


Exact values are exactly what they sound like. Examples would be a date or a user ID, but 
can also include exact strings like a username or an email address. The exact value "Foo" 
is not the same as the exact value "foo" . The exact value 2014 is not the same as the 
exact value 2014-09-15 . 


Full text, on the other hand, refers to textual data -- usually written in some human language 
-- like the text of a tweet or the body of an email. 


Full text is often referred to as “‘unstructured data", which is a misnomer -- natural language 
is highly structured. The problem is that the rules of natural languages are complex which 
makes them difficult for computers to parse correctly. For instance, consider this sentence: 


May is fun but June bores me. 


Does it refer to months or to people? 


Exact values are easy to query. The decision is binary -- a value either matches the query, or 
it doesn't. This kind of query is easy to express with SQL: 


WHERE name = "John Smith" 
AND user_id = 2 
AND date > "2014-09-15" 


Querying full text data is much more subtle. We are not just asking Does this document match 
the query'', but How well does this document match the query?" In other words, how 
relevant is this document to the given query? 


We seldom want to match the whole full text field exactly. Instead, we want to search within 
text fields. Not only that, but we expect search to understand our intent: 


e a search for "ux" should also return documents mentioning the "united Kingdom" 


e asearch for "jump" should also match "jumped" , "jumps" , "jumping" and perhaps 
even "leap" 


e "Johnny walker" should match "Johnnie walker" and "johnnie depp" should match 
"Johnny Depp" 


e "fox news hunting" should return stories about hunting on Fox News, while "fox 
hunting news" should return news stories about fox hunting. 


In order to facilitate these types of queries on full text fields, Elasticsearch first analyzes the 
text, then uses the results to build an inverted index. We will discuss the inverted index and 
the analysis process in the next two sections. 


反 向 索引 


Elasticsearch uses a structure called an inverted index which is designed to allow very fast 
full text searches. An inverted index consists of a list of all the unique words that appear in 
any document, and for each word, a list of the documents in which it appears. 


For example, let's say we have two documents, each witha content field containing: 


1. `The quick brown fox jumped over the lazy dog" 
2. ~Quick brown foxes leap over lazy dogs in summer" 


To create an inverted index, we first split the content field of each document into separate 
words (which we call terms or tokens), create a sorted list of all the unique terms, then list in 
which document each term appears. The result looks something like this: 


Term Doc_1 Doc 2 
Quick | | xX 
The | X | 
brown | X | x 
dog Ox | 
dogs | | xX 
fox | X | 
foxes | | xX 
in | | xX 
jumped | X | 
lazy | X | xX 
leap | | xX 
over | X | xX 
quick | X | 
summer | | xX 
the | X | 


Now, if we want to search for "quick brown" we just need to find the documents in which 
each term appears: 


Term Doc_1 Doc 2 
brown | X | xX 
quick | X | 


Both documents match, but the first document has more matches than the second. If we 
apply a naive similarity algorithm which just counts the number of matching terms, then we 
can say that the first document is a better match -- is more relevant to our query -- than the 
second document. 


But there are a few problems with our current inverted index: 


1. "Quick" and "quick" appear as separate terms, while the user probably thinks of 
them as the same word. 


2. "fox" and "foxes" are pretty similar, as are "dog" and "dogs" -- they share the 
same root word. 


3. "jumped" and "leap" , while not from the same root word, are similar in meaning -- 
they are synonyms. 


With the above index, a search for "+Quick +fox" wouldn't match any documents. 
(Remember, a preceding + means that the word must be present). Both the term "quick" 
and the term "fox" have to be in the same document in order to satisfy the query, but the 
first doc contains "quick fox" andthe second doc contains "Quick foxes" . 


Our user could reasonably expect both documents to match the query. We can do better. 


If we normalize the terms into a standard format, then we can find documents that contain 
terms that are not exactly the same as the user requested, but are similar enough to still be 
relevant. For instance: 


1. "Quick" can be lowercased to become "quick" . 


2. "foxes" can be stemmed -- reduced to its root form -- to become "fox" . Similarly 
"dogs" could be stemmed to "dog" . 


3. "jumped" and "leap" are synonyms and can be indexed as just the single term 


wj ump" 


Now the index looks like this: 


brown | X | xX 
dog | X | xX 
fox | X | xX 
in | | xX 
jump EOX X 
lazy | X | xX 
over | X | Xx 
quick | X | xX 
summer | | xX 
the | X | xX 


But we're not there yet. Our search for "+Quick +fox" would still fail, because we no longer 

have the exact term "Quick" in our index. However, if we apply the same normalization 

rules that we used on the content field to our query string, it would become a query for 
"+quick +fox" , which would match both documents! 


IMPORTANT: This is very important. You can only find terms that actually exist in your index, 
so: both the indexed text and and query string must be normalized into the same form. 


This process of tokenization and normalization is called analysis, which we discuss in the 
next section. 


[[analysis-intro]] === Analysis and analyzers 
Analysis is the process of: 


e first, tokenizing a block of text into individual terms suitable for use in an inverted index, 
e then normalizing these terms into a standard form to improve their ``searchability" or 
recall. 


This job is performed by analyzers. An analyzer is really just a wrapper which combines 
three functions into a single package: 


Character filters:: 


First, the string is passed through any _character filters_ in turn. Their 
job is to tidy up the string before tokenization. A character filter could 
be used to strip out HTML, or to convert ~"&"~ characters to the word 
anande J 


Tokenizer:: 


Next, the string is tokenized into individual terms by a tokenizer. A simple tokenizer might 
split the text up into terms whenever it encounters whitespace or punctuation. 


Token filters:: 


Last, each term is passed through any token filters in turn, which can change terms (eg 
lowercasing "Quick" ), remove terms (eg stopwords like "a" , "and" , "the" etc) or add 
terms (eg synonyms like "jump" and "leap" ) 


Elasticsearch provides many character filters, tokenizers and token filters out of the box. 
These can be combined to create custom analyzers suitable for different purposes. We will 
discuss these in detail in <>. 


==== Built-in analyzers 


However, Elasticsearch also ships with a number of pre-packaged analyzers that you can 
use directly. We list the most important ones below and, to demonstrate the difference in 
behaviour, we show what terms each would produce from this string: 


"Set the shape to semi-transparent by calling set_trans(5)" 


Standard analyzer:: 


The standard analyzer is the default analyzer that Elasticsearch uses. It is the best general 
choice for analyzing text which may be in any language. It splits the text on word 
boundaries, as defined by the http://www.unicode.org/reports/tr29/[Unicode Consortium], 


and removes most punctuation. Finally, it lowercases all terms. It would produce: + set, the, 
shape, to, semi, transparent, by, calling, set_trans, 5 


Simple analyzer:: 


The simple analyzer splits the text on anything that isn't a letter, and lowercases the terms. It 
would produce: + set, the, shape, to, semi, transparent, by, calling, set, trans 


Whitespace analyzer:: 


The whitespace analyzer splits the text on whitespace. It doesn't lowercase. It would 
produce: + Set, the, shape, to, semi-transparent, by, calling, set_trans(5) 


Language analyzers:: 


Language-specific analyzers are available for many languages. They are able to take the 

peculiarities of the specified language into account. For instance, the english analyzer 

comes with a set of English stopwords -- common words like and or the which don't have 

much impact on relevance -- which it removes, and it is able to stem English words because 

it understands the rules of English grammar. + The english analyzer would produce the 

following: + set, shape, semi, transpar, call, set tran, 5+ Note how "transparent" , 
"calling" , and "set_trans" have been stemmed to their root form. 


==== When analyzers are used 


When we index a document, its full text fields are analyzed into terms which are used to 
create the inverted index. However, when we search on a full text field, we need to pass the 
query string through the same analysis process, to ensure that we are searching for terms in 
the same form as those that exist in the index. 


Full text queries, which we will discuss later, understand how each field is defined, and so 
they can do the right thing: 


e When you query a full text field, the query will apply the same analyzer to the query 
string to produce the correct list of terms to search for. 


e When you query an exact value field, the query will not analyze the query string, but 
instead search for the exact value that you have specified. 


Now you can understand why the queries that we demonstrated at the <> return what they 
do: 


e The date field contains an exact value: the single term "2014-09-15" . 
e The _all field is a full text field, so the analysis process has converted the date into 
the three terms: "2014" , "09" and "15". 


When we query the _all field for 2014 , it matches all 12 tweets, because all of them 
contain the term 2014 : 


[source,sh] 


GET /_ search?q=2014 # 12 results 


// SENSE: 052_Mapping_Analysis/25_Data_type_differences.json 


When we query the _all field for 2014-09-15 , it first analyzes the query string to produce 
a query which matches any of the terms 2014 , 09 or 15 . This also matches all 12 tweets, 
because all of them contain the term 2014 : 


[source,sh] 


GET / search?q=2014-09-15 # 12 results ! 


// SENSE: 052_Mapping_Analysis/25_Data_type_differences.json 


When we query the date field for 2014-09-15 , it looks for that exact date, and finds one 
tweet only: 


[source,sh] 


GET /_ search?q=date:2014-09-15 # 1 result 


// SENSE: 052_Mapping_Analysis/25_Data_type_differences.json 


When we query the date field for 2014 , it finds no documents because none contain that 
exact date: 


[source,sh] 


GET /_search?q=date:2014 # 0 results ! 


// SENSE: 052_Mapping_Analysis/25_Data_type_differences.json 


[[analyze-api]] ==== Testing analyzers 


Especially when you are new to Elasticsearch, it is sometimes difficult to understand what is 
actually being tokenized and stored into your index. To better understand what is going on, 
you can use the analyze API to see how text is analyzed. Specify which analyzer to use in 
the query string parameters, and the text to analyze in the body: 


[source,js] 


GET /_analyze?analyzer=standard 


Text to analyze 


// SENSE: 052_Mapping_Analysis/40_Analyze.json 


Each element in the result represents a single term: 


[source,js] 


{ "tokens": [ { "token": "text", "start_offset": 0, "end_offset": 4, "type": "", "position": 1 }, { 


"token": "to", "start_offset": 5, "end_offset": 7, "type": "", "position": 2 }, { "token": "analyze", 
"start_offset": 8, "end_offset": 15, "type": "", "position": 3 } ] 


} 


The token is the actual term that will be stored in the index. The position indicates the 
order in which the terms appeared in the original text. The start_offset and end_offset 
indicate the character positions that the original word occupied in the original string. 


The analyze API is really useful tool for understanding what is happening inside 
Elasticsearch indices, and we will talk more about it as we progress. 


==== Specifying analyzers 


When Elasticsearch detects a new string field in your documents, it automatically configures 
it as a full text string field and analyzes it with the standard analyzer. 


You don't always want this. Perhaps you want to apply a different analyzer which suits the 
language your data is in. And sometimes you want a string field to be just a string field -- to 
index the exact value that you pass in, without any analysis, such as a string user ID or an 


internal status field or tag. 


In order to achieve this, we have to configure these fields manually by specifying the 
mapping. 


映射 


As explained in <>, each document in an index has a type. Every type has its own mapping 
or schema definition. A mapping defines the fields within a type, the datatype for each field, 
and how the field should be handled by Elasticsearch. A mapping is also used to configure 

metadata associated with the type. 


We discuss mappings in detail in <>. In this section we're going to look at just enough to get 
you started. 


[[core-fields]] ==== Core simple field types 
Elasticsearch supports the following simple field types: 


[horizontal] String: :: string Whole number: :: byte , short , integer , long Floating 
point: :: float , double Boolean: :: boolean Date: :: date 


When you index a document which contains a new field -- one previously not seen -- 
Elasticsearch will use <> to try to guess the field type from the basic datatypes available in 
JSON, using the following rules: 


[horizontal] JSON type: :: Field type: 


Boolean: true or false :: "boolean" 
Whole number: 123 :: "long" 

Floating point: 123.45 :: "double" 
String, valid date: "2014-09-15" :: "date" 
String: "foo bar" :: "string" 


NOTE: This means that, if you index a number in quotes -- "123" it will be mapped as type 
"string" ,nottype "long" . However, if the field is already mapped as type "long" , then 
Elasticsearch will try to convert the string into a long, and throw an exception if it can't. 


==== Viewing the mapping 


We can view the mapping that Elasticsearch has for one or more types in one or more 
indices using the /_mapping endpoint. At the <> we already retrieved the mapping for type 
tweet in index gb: 


[source,js] 


GET /gb/_mapping/tweet 


This shows us the mapping for the fields (called properties) that Elasticsearch generated 
dynamically from the documents that we indexed: 


[source,js] 


{ "gb": { "mappings": { "tweet": { "properties": { "date": { "type": "date", "format": 


"dateOptionalTime" }, "name": { "type": "string" }, "tweet": { "type": "string" }, "user_id": { 
"type": "long" }}}}} 


[TIP] 


Incorrect mappings, such as having an age field mapped as type string instead of 
integer , Can produce confusing results to your queries. 


Instead of assuming that your mapping is 
correct, check it! 


[[custom-field-mappings]] ==== Customizing field mappings 


The most important attribute of a field is the type . For fields other than string fields, you 
will seldom need to map anything other than type : 


[source,js] 


{ "number_of_clicks": { "type": "integer" } 


} 


Fields of type "string" are, by default, considered to contain full text. That is, their value 
will be passed through an analyzer before being indexed and a full text query on the field will 
pass the query string through an analyzer before searching. 


The two most important mapping attributes for string fields are index and analyzer . 


The index attribute controls how the string will be indexed. It can contain one of three 
values: 


[horizontal] analyzed :: First analyze the string, then index it. In other words, index this field 
as full text. 


not_analyzed :: Index this field, so it is searchable, but index the value exactly as specified. 
Do not analyze it. 


no :: Don't index this field at all. This field will not be searchable. 


The default value of index fora string field is analyzed . If we want to map the field as 
an exact value, then we need to set it to not_analyzed : 


[source,js] 


{ "tag": { "type": "string", "index": "not_analyzed" } 


The other simple types -- long , double , date etc -- also accept the index parameter, 
but the only relevant values are no and not_analyzed , as their values are never analyzed. 


===== analyzer 


For analyzed string fields, use the analyzer attribute to specify which analyzer to apply 
both at search time and at index time. By default, Elasticsearch uses the standard 
analyzer, but you can change this by specifying one of the built-in analyzers, such as 


whitespace , simple , Of english 


[source,js] 


{ "tweet": { "type": "string", "analyzer": "english" } 


} 


In <> we will show you how to define and use custom analyzers as well. 
==== Updating a mapping 


You can specify the mapping for a type when you first create an index. Alternatively, you can 
add the mapping for a new type (or update the mapping for an existing type) later, using the 
/_mapping endpoint. 


[IMPORTANT] 


While you can add to an existing mapping, you can't change it. If a field already exists in the 
mapping, then it probably means that data from that field has already been indexed. If you 
were to change the field mapping, then 


the already indexed data would be wrong 
and would not be properly searchable. 


We can update a mapping to add a new field, but we can't change an existing field from 


analyzed tO not_analyzed . 


To demonstrate both ways of specifying mappings, let's first delete the gb index: 
[source,sh] 


DELETE /gb 


// SENSE: 052_Mapping_Analysis/45_Mapping.json 


Then create a new index, specifying that the tweet field should use the english analyzer: 


[source,js] 


PUT /gb <1> { "mappings": { "tweet" : { "properties" : { "tweet" : { "type" : "string", "analyzer": 


"english" }, "date" : { "type" : "date" }, "name": { "type" : "string" }, "user_id" : { "type" : "long" } 
}}} 


} 


// SENSE: 052_Mapping_Analysis/45_Mapping.json 
<1> This creates the index with the mappings specified in the body. 


Later on, we decide to add anew not_analyzed textfield called tag tothe tweet 
mapping, using the _mapping endpoint: 


[source,js] 


PUT /gb/_mapping/tweet { "properties" : { "tag" : { "type" : "string", "index": "not_analyzed" } } 


} 


// SENSE: 052_Mapping_Analysis/45_Mapping.json 


Note that we didn't need to list all of the existing fields again, as we can't change them 
anyway. Our new field has been merged into the existing mapping. 


==== Testing the mapping 


You can use the analyze API to test the mapping for string fields by name. Compare the 
output of these two requests: 


[source,js] 


GET /gb/_analyze?field=tweet Black-cats <1> 


GET /gb/_analyze?field=tag 


Black-cats <1> 


// SENSE: 052_Mapping_Analysis/45_Mapping.json 
<1> The text we want to analyze is passed in the body. 


The tweet field produces the two terms "black" and "cat" , while the tag field 
produces the single term "Black-cats" . In other words, our mapping is working correctly. 
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[[complex-core-fields]] === Complex core field types 


Besides the simple scalar datatypes that we mentioned above, JSON also has null 
values, arrays and objects, all of which are supported by Elasticsearch: 


==== Multi-value fields 


It is quite possible that we want our tag field to contain more than one tag. Instead of a 
single string, we could index an array of tags: 


of Meets isearch nosoql ly 


There is no special mapping required for arrays. Any field can contain zero, one or more 
values, in the same way as a full text field is analyzed to produce multiple terms. 


By implication, this means that all of the values of an array must be of the same datatype. 
You can't mix dates with strings. If you create a new field by indexing an array, Elasticsearch 
will use the datatype of the first value in the array to determine the type of the new field. 


The elements inside an array are not ordered. You cannot refer to the first element'' 
or the last element". Rather think of an array as a bag of values. 


==== Empty fields 


Arrays can, of course, be empty. This is the equivalent of having zero values. In fact, there is 
no way of storing a null value in Lucene, so a field with a null value is also considered 
to be an empty field. 


These four fields would all be considered to be empty, and would not be indexed: 


"empty_string": eer 


"null_value": null, 
"empty_array": LI, 
"array_with_null_value": [ null ] 


==== Multi-level objects 


The last native JSON datatype that we need to discuss is the object -- known in other 
languages as hashes, hashmaps, dictionaries or associative arrays. 


Inner objects are often used to embed one entity or object inside another. For instance, 
instead of having fields called user_name and user_id inside our tweet document, we 
could write it as: 


“js { "tweet": "Elasticsearch is very flexible", "user": { "id": "@johnsmith", "gender": "male", 
"age": 26, "name": { "full": "John Smith", "first": "John", "last": "Smith" } } 


} 


==== Mapping for inner objects 


Elasticsearch will detect new object fields dynamically and map them as type object , with 
each inner field listed under properties : 


[source,js] 


{ "gb": { "tweet": { <1> "properties": { "tweet": { "type": "string" }, "user": { <2> "type": "object", 


"properties": { "id": { "type": "string" }, "gender": { "type": "string" }, "age": { "type": "long" }, 


"name": { <2> "type": "object", "properties": { "full": { "type": "string" }, "first": { "type": "string" 
}, "last": { "type": "string" }}}}}}}} 


} 


<1> Root object. 
<2> Inner objects. 


The mapping for the user and name fields have a similar structure to the mapping for the 
tweet type itself. In fact, the type mapping is just a special type of object mapping, 

which we refer to as the root object. It is just the same as any other object, except that it has 

some special top-level fields for document metadata, like _source , the _all field etc. 


==== How inner objects are indexed 


Lucene doesn't understand inner objects. A Lucene document consists of a flat list of key- 
value pairs. In order for Elasticsearch to index inner objects usefully, it converts our 
document into something like this: 


[source,js] 


{ "tweet": [elasticsearch, flexible, very], "user.id": [@johnsmith], "user.gender": [male], 
"user.age": [26], "user.name.full": [john, smith], "user.name.first": [john], "user.name.last": 
[smith] 


} 


Inner fields can be referred to by name, eg "first" . To distinguish between two fields that 
have the same name we can use the full path, eg "user.name.first" Or even the type 
name plus the path: "tweet.user.name.first" . 


NOTE: In the simple flattened document above, there is no field called user and no field 
called user.name . Lucene only indexes scalar or simple values, not complex datastructures. 


==== Arrays of inner objects 


Finally, consider how an array containing inner objects would be indexed. Let's say we have 
a followers array which looks like this: 


[source,js] 


{ "followers": [ { "age": 35, "name": "Mary White"}, { "age": 26, "name": "Alex Jones"}, { "age": 
19, "name": "Lisa Smith"} ] 


} 


This document will be flattened as we described above, but the result will look like this: 


[source,js] 


{ "followers.age": [19, 26, 35], "followers.name": [alex, jones, lisa, smith, mary, white] 


} 


The correlation between {age: 35} and {name: Mary white} has been lost as each multi- 
value field is just a bag of values, not an ordered array. This is sufficient for us to ask: 


e Is there a follower who is 26 years old? 


but we can't get an accurate answer to: 


e Is there a follower who is 26 years old and who is called Alex Jones? 


Correlated inner objects, which are able to answer queries like these, are called nested 
objects, and we will discuss them later on in <>. 


